Sign in to follow this  

Program crash before main(), in some other lib

This topic is 4703 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Ok, this problem is very, very annoying, and have no clue why it happens, much less how to fix it. Basically, under Windows, the program crashes even before reaching the main function. But under Linux it works OK. To make things worse, it crashes in a library, libxml2.dll And to make things even worse, when run under GDB, the program doesn't crash at all. The program is written in C, so there are no methods and such that could crash it before it reaches main() Another very strange thing is, libxml2.dll needs zlib1.dll. Now, we do not use, or need zlib1.dll, but libxml needs it. Well, on some computers relplacing the zlib1.dll with some other version works. But on other computers it doesn't work. This is extremely annoying, and we are kind of tired, so I decided to post here, maybe someone can help? As for posting the code, there is no way you can help us, the code has about 40K lines of code, and like I said, it crashes before main()

Share this post


Link to post
Share on other sites
Did you build libxml2.dll yourself? libxml requires zlib because it can read and write compressed xml files (and they are compressed using zlib). You can build libxml without zlib support though. Make sure you have the right versions of the various dlls. Your build of libxml2.dll requires a specific version of zlib1.dll; although you can replace it with another version, dlls aren't still magically swappable like that and if the external interface has changed you may have strange crashes.

cheers
sam.

Share this post


Link to post
Share on other sites
No, we got the version from their web site. But the program DID work before, until some modifications were made.
We are thinking of building it ourselves, but I have no idea how to do that with DevCPP

Share this post


Link to post
Share on other sites
I have had this kind of crashes before and then it was due to a wrong version of a dll. You could always make a blank project with your current project settings to pin down that if it's a library problem.

Share this post


Link to post
Share on other sites
Quote:
Original post by doho
I have had this kind of crashes before and then it was due to a wrong version of a dll. You could always make a blank project with your current project settings to pin down that it's a library problem.


Yes, but the god damn thing worked fine...
Does it matter if you add new functions from that DLL, even if you don't use them?

Share this post


Link to post
Share on other sites
Quote:
Original post by Raduprv
Does it matter if you add new functions from that DLL, even if you don't use them?

I don't know.

You could always consider linking staticlly if that solves your problem. Unless you have multiple executables in your project there is nothing to gain from linking with dll's.

Share this post


Link to post
Share on other sites
Quote:
Original post by Raduprv
Ok, new info. It works FINE when using the win2k compatibility mode. Same exe, same dlls...
Interesting. Maybe you can post on MSDN newsgroups about this.

Share this post


Link to post
Share on other sites
Quote:
Original post by doho
Quote:
Original post by Raduprv
Ok, new info. It works FINE when using the win2k compatibility mode. Same exe, same dlls...

Interesting. Maybe you can post on MSDN newsgroups about this.


Any link to the MSDN group? Preferably to a web interface.

Share this post


Link to post
Share on other sites
Quote:
Original post by antareus
Well, have you looked at the assembly at the point where it crashed? Or used the address of where it crashed to figure out what module it occured in?


No, I didn't. Like I said, it doesn't crash when run under gdb. As for the module where it crashes, it's libxml2.dll

Share this post


Link to post
Share on other sites
Quick brain dump:
1) C does indeed make possible calling functions before main (static initializers).
2) I believe WinXP removed the DllInitialize function from some system DLLs, therefore shifting all ordinals by 1. Any chance the DLL is "bound" to those?
3) Make sure all DLLs passing around pointers to one another are compiled against the same runtime (use dependency walker).
4) Crash location can be determined by writing up a quick programm to query dbghelp, or looking for the address in libxml's map file.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
Those are open source libraries. I suggest building them from source, so you can easily debug the crash by just attaching the debugger at the point of crash.


That's the next thing we will do. I will have someone compile the DLLs (I don't know how to do that in DevCPP), and if that fails, then we will have to statically link with Libxml2 (I don't really liek this tho).

Quote:

Quick brain dump:
1) C does indeed make possible calling functions before main (static initializers).
2) I believe WinXP removed the DllInitialize function from some system DLLs, therefore shifting all ordinals by 1. Any chance the DLL is "bound" to those?
3) Make sure all DLLs passing around pointers to one another are compiled against the same runtime (use dependency walker).
4) Crash location can be determined by writing up a quick programm to query dbghelp, or looking for the address in libxml's map file.


1. I don't think our application does that. But i'll ask the other devs if they did anything like that lately.
2. What exactly does that mean, and how can we find out?
3. Hmm... I got the DLLs from different sources, but they DID work before. to make things worse, some do work on some computers, but won't work on others.
4. How do I do that, using DevCPP?

Share this post


Link to post
Share on other sites
Quote:
2. What exactly does that mean, and how can we find out?

All "exported" things in the public interface of a dll have numbers associated with them, called ordinals. You can optionally obtain exported resources by ordinal rather than by name. Because ordinals are allocated to exported data simply by whatever order they're encountered in (AFAIK), the ordinal numbers may change if you insert or remove an item. Because of this, it's not a good idea to load by ordinal, although I really doubt anyone would've done this.

Share this post


Link to post
Share on other sites
Quote:
3. Hmm... I got the DLLs from different sources, but they DID work before. to make things worse, some do work on some computers, but won't work on others.

Any chance of finding out the last good config, and looking at all changes from there? Are ya'll in source control?

Quote:
4. How do I do that, using DevCPP?

Ooh, sorry, no idea. I don't think GCC can be made to emit dbghelp-readable debug info, so that's out. I also don't know the cmdline param to generate a map file.

Quote:
Oh, we don't load our libraries manually, we let the OS do that for us (since the game is multiplatform).

The import address table in a DLL can reference other DLLs via ordinal (instead of the normal name lookup). That's rare, though - probably not what's happening.

Share this post


Link to post
Share on other sites
Quote:
Original post by Jan Wassenberg
Any chance of finding out the last good config, and looking at all changes from there? Are ya'll in source control?


Not really... Most of the new changes were done by the Linux devs, so they didn't notice any problems until a few days ago, when we compiled the windows binary for the update (which was supposed to be yesterday).
Besides, the crash is kind of chaotic, even if we find the last version it didn't crash that might not help us too much, because if the code that makes it crash is bug free, then we are still stuck...

Share this post


Link to post
Share on other sites
hmm, not good.
I guess it's too much to expect devs to test on both platforms before committing, but you at least need a record of all that has changed, so you can check the diffs for bugs. After this blows over, getting into source control is strongly recommended :)

Quote:
Besides, the crash is kind of chaotic, even if we find the last version it didn't crash that might not help us too much, because if the code that makes it crash is bug free, then we are still stuck...

hehe, if it's bug free, it should by definition not cause a crash :) It is possible you are dealing with a Windows bug, but those are rare unless messing around at low level.

If there's no record of changes (including having the Linux guys write up everything they remember doing), I guess there's nothing left to do but recompile the libraries from source (bonus: bake in a good memory tracker).

Share this post


Link to post
Share on other sites
Quote:
Original post by Jan Wassenberg
hmm, not good.
I guess it's too much to expect devs to test on both platforms before committing, but you at least need a record of all that has changed, so you can check the diffs for bugs. After this blows over, getting into source control is strongly recommended :)

We do have a CVS, and we can track down the changes and such, but we are talking about an MMORPG client here, and it's hard to back up to previous versions since some configuration files andpaths were changed, etc.

Quote:

hehe, if it's bug free, it should by definition not cause a crash :) It is possible you are dealing with a Windows bug, but those are rare unless messing around at low level.

I tend to believe it is a windows bug, because:
1. Works fine under Linux.
2. Works fine under Windows if the code is run under GDB
3. Works fine under Windows (on some computers) if a dll is changed with another (dll that we don't even use)
4. Works fine on Windows if run under Win2k compatibility mode.

Quote:

If there's no record of changes (including having the Linux guys write up everything they remember doing), I guess there's nothing left to do but recompile the libraries from source (bonus: bake in a good memory tracker).


I think we'd rather do that :)

Share this post


Link to post
Share on other sites
Ok, I think I fixed it.
I downloaded the latest versions of libxml2 and iconv, replaced all the includes, libs and dlls, and also included iconv.h (previously I defined it out). No idea why it works, but it works, so I can't complain.

Share this post


Link to post
Share on other sites

This topic is 4703 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this