| View previous topic :: View next topic |
| Author |
Message |
dot-borg
Joined: 26 Dec 2007
Posts: 1
|
 Posted: Wed Dec 26, 2007 8:19 pm Post subject: Segfault in GtkD.init() |
 |
|
Hi, I got the gtkd source from SVN, built and installed it using dsss (GDC on amd64 GNU/Linux). To make sure everything is working I tried a couple of the demo applications and they all produce a segfault in the GtkD.init() function.
Here's a backtrace from cairo_clock:
| Code: | Program received signal SIGSEGV, Segmentation fault.
0x00000000007ac998 in g_option_context_new ()
(gdb) bt
#0 0x00000000007ac998 in g_option_context_new ()
#1 0x00002ac639e691b0 in gtk_parse_args () from /usr/lib/libgtk-x11-2.0.so
#2 0x00002ac639e69249 in gtk_init_check () from /usr/lib/libgtk-x11-2.0.so
#3 0x00002ac639e69279 in gtk_init () from /usr/lib/libgtk-x11-2.0.so
#4 0x00000000004d6495 in _D3gtk4GtkD4GtkD4initFPiPPPaZv (argc=0x7fff71a8e95c,
argv=0x7fff71a8e950) at gtk/GtkD.d:281
#5 0x00000000004d63c2 in _D3gtk4GtkD4GtkD4initFAAaZv (args=
{length = 1, ptr = 0x7bb480}) at gtk/GtkD.d:151
#6 0x00000000004c991b in _Dmain (args={length = 1, ptr = 0x7bb480})
at main.d:33
#7 0x00000000005163f8 in _D9dgccmain211_d_run_mainUiPPaPUAAaZiZi2goMFZv ()
#8 0x00000000005164ac in _d_run_main ()
#9 0x00002ac639a01b74 in __libc_start_main () from /lib/libc.so.6
#10 0x00000000004c9869 in _start ()
(gdb) |
|
|
| Back to top |
|
 |
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Thu Dec 27, 2007 1:04 am Post subject: |
|
|
This is known problem #1 with gdc. It is being investigated. See ticket #4
This one specifically appears to be a problem related to dsss use (which uses gdmd to compile the source files). To test whether dsss is truly the problem, we need to throw together a makefile to build the gtkD library and the demos with gdc (not gdmd). I'm no makefile expert, but I'll be looking into this unless someone else manages to do so before me. 
(NOTE that only gtk and cairo demos compile and link; all other demos trigger gdc problem #2 in the link stage: undefined symbol errors related to enum structure. This is a codegen issue in gdc 0.24).
-JJR |
|
| Back to top |
|
|
Pse
Joined: 13 Dec 2007
Posts: 36
|
| Posted: Thu Dec 27, 2007 2:21 pm Post subject: |
|
|
Please use DMD for now if possible.
JJR, I'll try to cook up a makefile tomorrow. Mike seems to have the same problem when building by hand, though. |
|
| Back to top |
|
|
Mike Wey
Joined: 07 May 2007
Posts: 428
|
| Posted: Fri Dec 28, 2007 9:20 am Post subject: |
|
|
Done some more testing with gdc.
If i compile everything with gdc-0.24 eg: libgtkd.a and the demos/gtkD example.
Except for the demos/gtkD/TestTreeView1.d witch i compile with gdc-0.23 and link everything together (gcc) i get an working example. I might be able to narrow down a bit more where the bad code is generated.
EDIT: it has something to do with the char** in TestTreeView1.d |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Fri Dec 28, 2007 10:00 am Post subject: |
|
|
Nice work! So it does appear to be a problem with dsss... except for the char**?
Thanks for testing this out, Mike.
-JJR |
|
| Back to top |
|
|
Mike Wey
Joined: 07 May 2007
Posts: 428
|
| Posted: Fri Dec 28, 2007 3:58 pm Post subject: |
|
|
When not using the char** in the gtkD example, i am able to build a working example with both gdc-0.24 directly and with dsss.
so this doesn't appear to be a problem with dsss. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Fri Dec 28, 2007 4:15 pm Post subject: |
|
|
Excellent! That's great to know. And I'm sure Gregor might even be a bit relieved.
So how do you workaround the char**? Are you referring to the GtkD.Init char** or the static char** in TestTreeView1.d. They appear to be two separate issues?
Specifically, does this work with the Cairo example as well? |
|
| Back to top |
|
|
Mike Wey
Joined: 07 May 2007
Posts: 428
|
| Posted: Fri Dec 28, 2007 4:21 pm Post subject: |
|
|
I spoke to soon, i was using dsss with the worn compiler, with dsss + gdc-0.24 there is still a segfault 
EDIT: note to self: read complete post before replying
| Quote: | | So how do you workaround the char**? Are you referring to the GtkD.Init char** or the static char** in TestTreeView1.d. They appear to be two separate issues? |
only the static char** in TestTreeView.d i replaced the 'new pixbuf(char**)' with 'new pixbuf(filename, null)' to get it to compile a working example.
An other EDIT: the cairo example work when manually the cairo example works but not with dsss.
this is related to the -rdynamic flagg dsss passes to gcc, because if i manualy compile if with that flag it has the same result as dsss. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Fri Dec 28, 2007 4:36 pm Post subject: |
|
|
I'm still a little confused...
So this only works with gdc 0.23 still? Does this work with gdc 0.23 and dsss? Does this work with gdc 0.24 sans dsss... if the workaround is in place? It's still not clear.
Maybe you can limit the confusion by posting results with the compiler (and version), OS, and related tools listed before each post. Then the details will be clear.
Nonetheless, thanks for investigating this.
I think there's still a hangup with GtkD.Init that needs to be dealt with. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Fri Dec 28, 2007 4:41 pm Post subject: |
|
|
| Mike Wey wrote: | An other EDIT: the cairo example work when manually the cairo example works but not with dsss.
this is related to the -rdynamic flagg dsss passes to gcc, because if i manualy compile if with that flag it has the same result as dsss. |
Ah ok... good to know that this is the issue with dsss... maybe we should send Gregor an email directly concerning this and also post a ticket to the dsss Trac.
I'm not familiar with what the flag does, but I'll look into it. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Fri Dec 28, 2007 4:47 pm Post subject: |
|
|
| Mike Wey wrote: | An other EDIT: the cairo example work when manually the cairo example works but not with dsss.
this is related to the -rdynamic flagg dsss passes to gcc, because if i manualy compile if with that flag it has the same result as dsss. |
Apparently this is what the -rdynamic flag does:
| Quote: | The -rdynamic option is slightly different. It seems to have been
introduced as a high-level interface to the linker, to (a) force the
allocation of a global symbol table in the final executable, even if it's
not strictly needed, and (b) cause the inclusion of the global symbols in
that symbol table.
o Under linux, gcc interprets it by setting the
"-export-dynamic" option for ld, which has that effect, according
to the linux ld manpage.
o Under IRIX it's ignored, and the program's happy as a clam.
o Under SunOS-4.1, gcc interprets it by setting the -dc -dp
options for ld, which again forces the allocation of the symbol
table in the code produced (see ld(1) on a Sun).
Wonder if we should mailbomb gcc-bug@gnu.org until they fix their man/info
pages  |
From this link |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Fri Dec 28, 2007 4:55 pm Post subject: |
|
|
the gcc (4.1.2) manual says this:
| Quote: | -rdynamic
Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker to add all symbols, not only used ones, to the dynamic symbol table. This option is needed for some uses of dlopen or to allow obtaining backtraces from within a program. |
So I'm guessing that, at some point, having a working "-rdynamic" flag may be necessary for our project.
We should maybe post this as a bug report for gdc as well. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Fri Dec 28, 2007 5:04 pm Post subject: |
|
|
And one more quote for good measure and posterity, this time from the ld linker manual.
| Quote: | -E
--export-dynamic
When creating a dynamically linked executable, add all symbols to the dynamic symbol table. The dynamic symbol table is the set of symbols which are visible from dynamic objects at run time. If you do not use this option, the dynamic symbol table will normally contain only those symbols which are referenced by some dynamic object mentioned in the link. If you use dlopen to load a dynamic object which needs to refer back to the symbols defined by the program, rather than some other dynamic object, then you will probably need to use this option when linking the program itself. |
I'm not sure if I'm right... but it seems to me that the executables we are making are NOT dynamic objects or dynamic executables (in the sense that the symbols they contain are not meant to be shared with other dynamic objects);
Put another way, the gtk symbols in GtkD are just used to acquire other dynamic objects symbols (from the actual shared library)... not serve the symbols to other objects via our executable.
So strictly speaking, it appears that the flag -rdynamic is not intended for this specific situation. This would seem to apply to libraries like derelict as well, which are common in other projects (eg. guisterax).
This also implies that this is not a bug in gdc, but merely a misapplication of a linker switch in dsss.
I'm not sure, though.
Last edited by JJR on Fri Dec 28, 2007 5:29 pm; edited 2 times in total |
|
| Back to top |
|
|
Pse
Joined: 13 Dec 2007
Posts: 36
|
| Posted: Fri Dec 28, 2007 5:22 pm Post subject: |
|
|
I did try to get gtkD working with gdc-0.24 without passing any char** to gtk_init() but did not succeed. There's no point in putting more workarounds for a broken compiler, it's becoming a bit invasive. I think we should stick with gdc-0.23, if that works, until everything gets fixed upstream.
BTW, these are not the only problems we'll get trying to get gtkD to compile with gdc-0.24+, just look at the nice error message I got in ticket #1 after trying one of Mike's patches. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Fri Dec 28, 2007 5:38 pm Post subject: |
|
|
No... some of those error messages are... just really bad error messages. Not necessarily a "broken" compiler. Dmd was full of these problems for ages. So I guess gdc is lagging behind a bit. But, yes, I'm sure we've hit on several bugs, nonetheless.
The idea of implementing workarounds was suggested more as a diagnostic measure (to see if it worked) than a permanent fix. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
