Am 31.07.2012 um 02:03 schrieb Oliver Buchtala <oliver.buchtala@googlemail.com>:

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.
I think you understood me wrong. Examining the backtrace using gdb is a matter of seconds/minutes.
It said it was triggered by the emit_action call within the generation of the destructor function.
Sadly SWIG uese DOH as an object system, which isn't exactly nice to debug (afiacs).
So the real question was: Why would the given exception handler definition make the destructor call crash swig?
My question is about the real reason. Not the effect. It would be a nobrainer to fix the issue in place where NULL is dereferenced. But it isn't the origin of the problem. That lays somewhere else. Sadly I haven't seen too much exception handling code around in the C backend module to compare it to e.g. Java or C# code.

Thanks for your comment and advice anyway :)

Cheers,
Oliver