From: Tomasz G. <to...@wp...> - 2007-07-21 22:50:03
|
Hello. I'm hitting a problem with aforementioned error during starting applications compiled with mingw. The problem does not appear in all cases. Its somehow connected to cross dll dependencies (I'm using dynamic linking). Simple programs are working without problems but I can't guess what does it mean simple in this case. I have a Qt4 based application. I have compiled Qt on windows and my application compiled on linux using cross compiler provided by debian. My application is also divided (like Qt4) into many dlls. During starting application I get a window with this message before any my code is executed. Message appears on Win2000 and XP but (strangely) not when executing under wine. I've read many informations on the web about this exception but haven't found any informations about anything that would help me. At the moment I don't have a clue what can happen. I don't know what is the problem. I don't even have a clue how to debug such problems. Installing drmingw and running under gdb does not help. Gdb writes information about segmentation fault and a window appears with the "0xc0000005" message. After clicking ok I get segmentation fault messages from gdb two times more and: Program exited with code 030000000005. You can't do that without a process to debug. Do you have any suggestions? If more information is needed I'll try my best. Regards. Tomasz Gajewski |
From: Brian D. <br...@de...> - 2007-07-21 23:08:03
|
Tomasz Gajewski wrote: > During starting application I get a window with this message before > any my code is executed. Message appears on Win2000 and XP but > (strangely) not when executing under wine. Pseudo-relocs in the .rdata section. http://www.cygwin.com/ml/cygwin/2004-09/msg01101.html http://www.cygwin.com/ml/cygwin/2007-07/msg00470.html http://www.cygwin.com/ml/cygwin/2004-10/msg01052.html Brian |
From: Tomasz G. <to...@wp...> - 2007-07-22 10:10:58
|
Brian Dessent <br...@de...> writes: > Tomasz Gajewski wrote: > >> During starting application I get a window with this message before >> any my code is executed. Message appears on Win2000 and XP but >> (strangely) not when executing under wine. > > Pseudo-relocs in the .rdata section. > > http://www.cygwin.com/ml/cygwin/2004-09/msg01101.html > http://www.cygwin.com/ml/cygwin/2007-07/msg00470.html > http://www.cygwin.com/ml/cygwin/2004-10/msg01052.html Thank you very much. I understand generally what the problem is but it will not be enough to solve my problem. I have two choices now. First is to try the linker script provided in last given link and hope that it will still work after three years. I don't understand at all what this script performs and what are real (for program execution) consequences of not using .rdata section (performance?). Second way would be to find places where I have const structures which point to data from other dlls but code base I'm working on is quite big and highly modularized and I will not be able to find such problematic places just by guessing. I would need some tool to point me to such places. Is there something like this? One thing more. Would it help if I provided dllExport and dllImport clauses consistently in all code base instead of using auto import feature? Regards Tomasz Gajewski |
From: Brian D. <br...@de...> - 2007-07-22 12:16:30
|
Tomasz Gajewski wrote: > I have two choices now. First is to try the linker script provided in > last given link and hope that it will still work after three years. I You can diff it against the current version of the linker scripts (found in /mingw/usr/lib/ldscripts/) but I doubt much has changed. > don't understand at all what this script performs and what are real > (for program execution) consequences of not using .rdata section > (performance?). It would be a slight memory pessimization in that those pages could no longer be shared across multiple instances of your program/DLL, and possibly a very small performance impact, but I have no idea if either would be measurable except in pathological cases. > Second way would be to find places where I have const structures which > point to data from other dlls but code base I'm working on is quite > big and highly modularized and I will not be able to find such > problematic places just by guessing. I would need some tool to point > me to such places. Is there something like this? I don't know that any such tool exists, other than by manually scanning the assembler output. > One thing more. Would it help if I provided dllExport and dllImport > clauses consistently in all code base instead of using auto import > feature? As far as I know, yes, this is the preferred way of dealing with it as the whole pseudo-reloc mechanism was designed as a crutch for porting libraries/interfaces that were originally designed for ELF-like systems that require no explicit __declspec attributes for the compiler to emit the necessary indirection as the PLT and GOT take that role. But if you can modify your headers/interfaces to mark the symbols dllimport then the compiler should do the right thing and there will be no need for the pseudo-reloc machinery to have to fix-up the structures at program startup (and thus the need for them to be in a writable section.) Brian |
From: Tomasz G. <to...@wp...> - 2007-07-22 22:33:22
|
Brian Dessent <br...@de...> writes: > Tomasz Gajewski wrote: > >> I have two choices now. First is to try the linker script provided >> in last given link and hope that it will still work after three >> years. I > > You can diff it against the current version of the linker scripts > (found in /mingw/usr/lib/ldscripts/) but I doubt much has changed. I have made a version that seems to work by moving all content from .rdata section to .data (it seemed to me that this was the real change) but I have doubts about one line at the beginning that exists in "no-rdata" version and is not available in current: ENTRY(_mainCRTStartup) It is just after SEARCH_DIR and before SECTIONS. Do you know if it should exist in current "no-rdata" version? >> Second way would be to find places where I have const structures >> which point to data from other dlls but code base I'm working on is >> quite big and highly modularized and I will not be able to find >> such problematic places just by guessing. I would need some tool to >> point me to such places. Is there something like this? > > I don't know that any such tool exists, other than by manually > scanning the assembler output. I tried to study assembler generated by gcc but I couldn't find anything that could cause problems (till now I don't have a clue which part of my code triggers this exception). Do you know about some specific code which I should look for? >> One thing more. Would it help if I provided dllExport and dllImport >> clauses consistently in all code base instead of using auto import >> feature? > > As far as I know, yes, this is the preferred way of dealing with it > as the whole pseudo-reloc mechanism was designed as a crutch for > porting libraries/interfaces that were originally designed for > ELF-like systems that require no explicit __declspec attributes for > the compiler to emit the necessary indirection as the PLT and GOT > take that role. But if you can modify your headers/interfaces to > mark the symbols dllimport then the compiler should do the right > thing and there will be no need for the pseudo-reloc machinery to > have to fix-up the structures at program startup (and thus the need > for them to be in a writable section.) Maybe in the long term I will use this solution but there is much code it will probably not be an easy and quick task to do. > Brian Your answers were really helpful. Thank you very much. Regards Tomasz Gajewski |
From: Tomasz G. <to...@wp...> - 2007-07-24 19:28:02
|
Hi. > I have made a version that seems to work by moving all content from > .rdata section to .data (it seemed to me that this was the real > change). Just to let you know. I think this script doesn't solve all 0xc0000005 problems. I think that auto importing of vtables of class is not solved by this linker script but as I don't have much experience in this area I can't be sure. When using cppunit, test suites and subsuites in different dlls I experienced 0xc0000005 exception even with modified linker script. Anyway __declspec(dllimport) fixed the issue for me in this special case. Regards Tomasz Gajewski |
From: Brian D. <br...@de...> - 2007-07-23 08:52:12
|
Tomasz Gajewski wrote: > change) but I have doubts about one line at the beginning that exists > in "no-rdata" version and is not available in current: > > ENTRY(_mainCRTStartup) > > It is just after SEARCH_DIR and before SECTIONS. > > Do you know if it should exist in current "no-rdata" version? I doubt it matters. I'm pretty sure the entry point defaults to mainCRTStartup anyway so that line's probably a no-op, and if it's not present in the current MinGW binutils linker scripts it's definitely extraneous. Brian |
From: Brian D. <br...@de...> - 2007-07-23 10:04:04
|
Tomasz Gajewski wrote: > I tried to study assembler generated by gcc but I couldn't find > anything that could cause problems (till now I don't have a clue which > part of my code triggers this exception). Do you know about some > specific code which I should look for? Sorry, I may have led you astray here. The auto-import work is only done at link time, so really there is no way to see its results until after the final link. I did a little fooling around trying to automatically detect it, but in reality the best indicator that exists is already in front of you in the linker output: Info: resolving _<sym> by linking to __imp__<sym> (auto-import) Every one of these that you see in the linker output means that <sym> was a variable imported from a DLL without using explicit __declspec(dllimport) and thus will require these runtime fixups. And any const struct that is initialized with a pointer to <sym> will trigger the 0xc0000005 exception. > Maybe in the long term I will use this solution but there is much code > it will probably not be an easy and quick task to do. It's especially hard because you can't just slap a __declspec(dllimport) on the imported symbols because gcc will then know that these are not constant addresses and will refuse to let you use them in that context: extern __declspec(dllimport) int sym; struct { int *intptr; } foo = { &sym }; foo.c:2: error: initializer element is not constant foo.c:2: error: (near initialization for `foo.intptr') So you would have to change the code to explicitly assign to it as "foo.intptr = &sym;" at runtime rather than being able to initialize it as a struct. Leaving off dllimport and relying on auto-imports to fix-up the location is actually a lot easier, but it requires this pesky writable section. Brian |
From: Jesper Q. <jqu...@cl...> - 2007-07-23 09:12:44
|
Tomasz Gajewski wrote: > During starting application I get a window with this message before > any my code is executed. Message appears on Win2000 and XP but > (strangely) not when executing under wine. > > I've read many informations on the web about this exception but > haven't found any informations about anything that would help me. > > At the moment I don't have a clue what can happen. I don't know what > is the problem. I don't even have a clue how to debug such > problems Do You get an exit code ? Regargs Jesper Quorning |
From: Tomasz G. <to...@wp...> - 2007-07-23 10:56:29
|
Jesper Quorning <jqu...@cl...> writes: > Tomasz Gajewski wrote: >> During starting application I get a window with this message before >> any my code is executed. Message appears on Win2000 and XP but >> (strangely) not when executing under wine. >> >> I've read many informations on the web about this exception but >> haven't found any informations about anything that would help me. >> >> At the moment I don't have a clue what can happen. I don't know what >> is the problem. I don't even have a clue how to debug such >> problems > Do You get an exit code ? Only in gdb. Output below. (gdb) run Starting program: C:\TEMP\aa/test_gui_module_dlls.exe Program received signal SIGSEGV, Segmentation fault. <<< here the window appears and after clicking ok other >>> <<< messages appear >>> Program received signal SIGSEGV, Segmentation fault. Program received signal SIGSEGV, Segmentation fault. Program exited with code 030000000005. You can't do that without a process to debug. Currently I'm using a modified linker script as one of options suggested by Brian. I would be glad if I could find somehow where are "erroneous" places to fix them but I'm not aware of such method. Regards Tomasz Gajewski |
From: Jesper Q. <jqu...@cl...> - 2007-07-23 11:57:59
|
Tomasz Gajewski wrote: > Jesper Quorning <jqu...@cl...> writes: > > >> Tomasz Gajewski wrote: >> >>> During starting application I get a window with this message before >>> any my code is executed. Message appears on Win2000 and XP but >>> (strangely) not when executing under wine. >>> >>> At the moment I don't have a clue what can happen. I don't know what >>> is the problem. I don't even have a clue how to debug such >>> problems >>> >> Do You get an exit code ? >> > > Only in gdb. Output below. > > (gdb) run > Starting program: C:\TEMP\aa/test_gui_module_dlls.exe > > Program received signal SIGSEGV, Segmentation fault. > > <<< here the window appears and after clicking ok other >>> > <<< messages appear >>> > > Program received signal SIGSEGV, Segmentation fault. > > Program received signal SIGSEGV, Segmentation fault. > > Program exited with code 030000000005. > You can't do that without a process to debug. > > > Currently I'm using a modified linker script as one of options > suggested by Brian. I would be glad if I could find somehow where are > "erroneous" places to fix them but I'm not aware of such method. > I had a similar problem on a Server 2003 where Cygwin shell gave me error code 133. Also running fine under Wine. After long time trial/error/pure luck i found out my ptreadVC2.dll was not executable. --Jesper Quorning |
From: Tomasz G. <to...@wp...> - 2007-07-23 12:12:32
|
Jesper Quorning <jqu...@cl...> writes: > I had a similar problem on a Server 2003 where Cygwin shell gave me > error code 133. Also running fine under Wine. After long time > trial/error/pure luck i found out my ptreadVC2.dll was not > executable. Not sure what you mean by "not executable". Format of file? Anyway, changed linker script fixes the issue for me so I think your problem was different. Thanks anyway. Regards. Tomasz Gajewski |