Whilst pondering the debugging situation with our development builds, I was wondering if we can provide backtrace information in our builds in case of abnormal termination. Sk1p on IRC/Jabber pointed this out to me in the GLibC docs:
http://www.gnu.org/software/libc/manual/html_node/Backtraces.html#Backtraces
...it even has a code example.
I noticed that MinGW does support signals to some extent, so I removed the '#ifndef WIN32' switch from that part of inkscape.cpp. Likely inkscape_segv_handler() is now enabled on Win32.
Maybe we could add a backtrace to inkscape_segv_handler(), with a note asking the gentle user to send this to us? Maybe save it to a file?
Just an idea.
Bob
On Tue, 22 Jun 2004, Bob Jamison wrote:
I noticed that MinGW does support signals to some extent, so I removed the '#ifndef WIN32' switch from that part of inkscape.cpp. Likely inkscape_segv_handler() is now enabled on Win32.
This is good, although perhaps there are other WIN32 compilers that should be tested, just in case? It might be better to open this set of code only if the compiler is MinGW.
Maybe we could add a backtrace to inkscape_segv_handler(), with a note asking the gentle user to send this to us? Maybe save it to a file?
A cut and paste-able note with the backtrace would be a good idea. Might also want to print out a few key env vars or system params (OS version, etc.) and the url for the bug tracker.
Bryce
Bryce Harrington wrote:
On Tue, 22 Jun 2004, Bob Jamison wrote:
I noticed that MinGW does support signals to some extent, so I removed the '#ifndef WIN32' switch from that part of inkscape.cpp. Likely inkscape_segv_handler() is now enabled on Win32.
This is good, although perhaps there are other WIN32 compilers that should be tested, just in case? It might be better to open this set of code only if the compiler is MinGW.
Well, come to think of it, I don't think we have ever had a completely different compiler build this. A good test of our portability would be the free command-line version of Borland C++ 5.5, here: http://borland.com/products/downloads/download_cbuilder.html#
It is a very strict ANSI compiler.
Bob
On Tue, 22 Jun 2004, Bob Jamison wrote:
Well, come to think of it, I don't think we have ever had a completely different compiler build this. A good test of our portability would be the free command-line version of Borland C++ 5.5, here: http://borland.com/products/downloads/download_cbuilder.html#
It is a very strict ANSI compiler.
That's a good idea. Lauris had gotten Sodipodi to compile with MSVC, although I think there were some changes needed that are not in our codebase.
And I may not be remembering right, but I could swear someone else compiled with the cygwin compiler or djgpp, although that has been quite a while ago, so maybe it's no longer relevant.
Bryce
On Tue, 2004-06-22 at 13:46, Bryce Harrington wrote:
On Tue, 22 Jun 2004, Bob Jamison wrote:
Well, come to think of it, I don't think we have ever had a completely different compiler build this. A good test of our portability would be the free command-line version of Borland C++ 5.5, here: http://borland.com/products/downloads/download_cbuilder.html#
It is a very strict ANSI compiler.
That's a good idea. Lauris had gotten Sodipodi to compile with MSVC, although I think there were some changes needed that are not in our codebase.
I can guarantee you that Inkscape will not compile with a non-gcc compiler at this time.
Off the top of my head, two culprits would be my use of gcc's __attribute__ extension (fixable with a simple #define, though), and fred and I have both used a hash_map class which is specific to gcc's version of the SGI STL.
I think there are some other issues too, but that's all I remember at the moment.
And I may not be remembering right, but I could swear someone else compiled with the cygwin compiler or djgpp, although that has been quite a while ago, so maybe it's no longer relevant.
Those both use gcc also.
-mental
On Tue, 22 Jun 2004, MenTaLguY wrote:
On Tue, 2004-06-22 at 13:46, Bryce Harrington wrote:
On Tue, 22 Jun 2004, Bob Jamison wrote:
Well, come to think of it, I don't think we have ever had a completely different compiler build this. A good test of our portability would be the free command-line version of Borland C++ 5.5, here: http://borland.com/products/downloads/download_cbuilder.html#
It is a very strict ANSI compiler.
That's a good idea. Lauris had gotten Sodipodi to compile with MSVC, although I think there were some changes needed that are not in our codebase.
I can guarantee you that Inkscape will not compile with a non-gcc compiler at this time.
Off the top of my head, two culprits would be my use of gcc's __attribute__ extension (fixable with a simple #define, though), and fred and I have both used a hash_map class which is specific to gcc's version of the SGI STL.
Hmm... Yet another reason to consider using either the standard map<> template, or, if performance really is a serious issue, to implement a custom non-template version in the Inkscape codebase.
What does __attribute__ do? I haven't run across that before.
Bryce
On Tue, 2004-06-22 at 23:17, Bryce Harrington wrote:
Hmm... Yet another reason to consider using either the standard map<> template, or, if performance really is a serious issue, to implement a custom non-template version in the Inkscape codebase.
Or a custom template version. Nothing wrong with implementing a template container class that implements the appropriate STL interfaces.
What does __attribute__ do? I haven't run across that before.
It lets you provide hints to the compiler like e.g. "this function never returns", "this function has no side-effects", "this function shouldn't be discarded even though it's apparently unused", and "this is deprecated" (my favorite).
-mental
On Tue, 22 Jun 2004, MenTaLguY wrote:
On Tue, 2004-06-22 at 23:17, Bryce Harrington wrote:
Hmm... Yet another reason to consider using either the standard map<> template, or, if performance really is a serious issue, to implement a custom non-template version in the Inkscape codebase.
Or a custom template version. Nothing wrong with implementing a template container class that implements the appropriate STL interfaces.
True. IIRC, the STL developers had proposed some hash-based data structures including a hash map. Perhaps that is where hash_map came from. In any case, by now I'm sure some a good one could be found.
What does __attribute__ do? I haven't run across that before.
It lets you provide hints to the compiler like e.g. "this function never returns", "this function has no side-effects", "this function shouldn't be discarded even though it's apparently unused", and "this is deprecated" (my favorite).
Ahh, yes I guess I have run across that in your code. ;-)
Bryce
participants (3)
-
Bob Jamison -
Bryce Harrington -
MenTaLguY