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