Developed application crash with no (?) reason

[Freem]

I am currently facing a strange problem...
After some modifications in my project's source code, it is no longer able to be run inside C::B, in normal or debugger mode.

But when I am trying to run it from command line, everything seems to work perfectly, no crash, no exception... (well... at least software can be run, it is not stable at the moment)

I do not know if it is really a C::B bug, I have no clue on what is the problem: there is nothing in Code::Blocks 's log, only

Code Select Expand


Checking for existence: /home/berenger/autorealm/bin/debug/autorealm
Executing: x-terminal-emulator -T autorealm -e /home/berenger/autorealm/bin/debug/autorealm  (in /home/berenger/autorealm/bin/debug)
Process terminated with status 1 (0 minutes, 0 seconds)

in build log, and C::B survive to the application's crash.

When I try to debug it, it seem it does not even enter the wxWidget "App" class I made. At least, if I put a breakpoint on the first line which should be executed in my program, it seem to be never reached.

Thinking about wxWidgets... Maybe I made something stupid with project's options related to wxWidgets... but I can see what. And as I said, things works like a charm outside of C::B.

I actually have no idea about what is happening or which information I could add... Maybe  the problematic source? (https://bitbucket.org/bmorel/autorealm/changeset/60e9b3e05d48)

[oBFusCATed]

You app is not finding some shader library or there are missing symbols. Try -z defs in the other linker options for example.

[Freem]

I tried to add this "-z defs" in the main project, it did not change anything.
I will investigate further on this way now, thanks for the tip.

But how do you know it is a problem like that? C::B gave me no clue ??? I know that my libs are quite messy at the moment, but I thought that ld would have warned or insulted me if there were some errors. Is it because of C::B is loading libs which are not in the $PATH?
And, on this subject, what C::B do to say to the software where those libs are?
Maybe finding some help on those question will allow me to understand better those things. I am still a newbie when things come to running environment on Debian.

Erf... I realize that I should have said about my OS in my first post. And about my C::B's rev, which is the last nightly (8094)...

[oBFusCATed]

1. I know, because it has happened to me
2. C::B sets LD_LIBRARY_PATH (equivalent of PATH in windows) to include you library paths, so this can lead to your executable trying to load different libraries.
3. This is tough issue to fix
4. I'm not sure if we can do something about it, unfortunately.

[Freem]

1: I should have guessed that
2: I will try to play with that variable to see if I can do something similar with my command line
3: all issues are hard to fix when you have no clue about them, and just "process return -1" is not exactly what I think is a nice error report...
4: I guess OSes do not give more details than the -1 return code? If so, it will be hard, yes...

At least, thanks for your reply, I'll try to fix that .... problem.

[oBFusCATed]

2. There is a checkbox in the project->properties->debugger-> do not adjust ld_library_path which is off, you can test what happens if you enable it.
4. The dynamic loader prints some info, but I'm not sure if we can intercept it