Re: [Swig-devel] GSoC C backend report 10

[Oliver B. <oli...@go...>]

On 31.07.2012 01:50, Oliver Buchtala wrote:
> On 31.07.2012 01:41, Leif Middelschulte wrote:
>> Am Dienstag, 31. Juli 2012 um 01:25 schrieb Oliver Buchtala:
>>> On 31.07.2012 01:20, Leif Middelschulte wrote:
>>>> Hello everyone,
>>>>
>>>> Find a short summary of what I did during last week below.
>>>>
>>>> Tasks for the week were:
>>>> - Fix the reason for the crash of SWIGing pugixml header
>>>> - Write some atomic c++ feature tests
>>>>
>>>> What I did:
>>>> - Bisected test "special_variables" to trigger a swig crash with a 
>>>> sufficient amount of code:
>>>>
>>>> %inline %{
>>>> struct someStruct{};
>>>> %}
>>>>
>>>> %exception {
>>>>   declaration = "$fulldecl $decl";
>>>> }
>>>>
>>>> It turned out, that it's a dereferenced NULL access of strstr in 
>>>> Source/Swig/misc.c
>>>> I assumed that for some reason swig isn't meant to have save calls 
>>>> (maybe to prevent hiding "bugs" elsewhere) and had a look at what 
>>>> called it.
>>>> It is called when creating the destructor wrapper call. Since it 
>>>> didn't seem to be an important case and the solution wasn't obvious 
>>>> how to fix it in the c module, I postponed it.
>>>>
>>>> - Wrote some basic C++ feature tests. I complained about the way 
>>>> tests are written/named (multi feature composition/unrelated name) 
>>>> in earlier mails and therefore started to implement more basic 
>>>> tests, dedicated to single features or explicitly naming the 
>>>> features they test. These include nothing but what they name. The 
>>>> name "atomic" might be a bit misleading here (thanks William!) and 
>>>> might be soon renamed to "native" to resolve ambiguities with 
>>>> threading stuff.
>>>> - cpp_basic_class
>>>> - cpp_basic_class_enum
>>>>         - cpp_basic_class_method
>>>> - cpp_basic_class_var_pub_member_atom
>>>> - cpp_basic_class_var_pub_member_class
>>>>         - cpp_basic_global_enum
>>>>         - cpp_basic_global_var_atom
>>>>         - cpp_basic_global_var_class
>>>>         - cpp_basic_namespaced_class
>>>> - Implemented those tests for the C backend
>>>> - Fixed wrapper typemaps to only cast if type is complex/swig object
>>>> - Fixed partialcheck of C backend
>>>>
>>>> Running the partialcheck revealed that swig crashes once because of 
>>>> the reasons named above.
>>>>
>>>> What I didn't do:
>>>> I didn't continue to try to swig pugixml, because it's simply to 
>>>> huge and the benefit might be not worth it. It uses a lot of things 
>>>> that need manual treatment in the interface file.
>>>>
>>>> Tasks for this weeks are:
>>>> - Prioritize C++ features which don't work and repair them
>>>> [- Write more basic tests]
>>>>
>>>> -- 
>>>> Leif
>>>>
>>> Hi Leif,
>>>
>>> just a humble question:
>>> Wouldn't it be quicker to find out such errors using a debugger?
>> Thanks for your concerns. I used gdb to debug it.
>> But I wanted to know how to reproduce it. The C backend doesn't have 
>> problems with generating code for the destructor proxy/wrapper in 
>> general. It's just this very combination that triggers the crash. 
>> E.g. I don't see why it wasn't the constructor isn't affected. The 
>> exception handler definition doesn't seem to match specific functions.
>> If you are referring to your new swig debugger, I haven't had a look 
>> at it yet.
>>
> Ok. I don't know about the details...
> I just read about bisecting which gave me the impression of trial and 
> error.
>
> If you have the time to look at the gdb extensions, I really can 
> recommend it.
> I am using it on an hourly basis now ;). It is very helpful, as you 
> can travel around in the call stack...
> If it is not part of your reportoire right now... try to make it that.
>
> If you want to have a light-weight graphical debugger... look at 
> nemiver (but build your own from a later version).
>
> Regards,
> Oliver
>
BTW: identifying the cause of a segfault should not take more than 
30mins using a good debugger.
A debugger will stop at the point of failure, allowing you to examine 
the call stack and preconditions on every level.
This way you usually find out the exact case, even an obscure one.

Cheers,
Oliver