User forums > Help

Developed application crash with no (?) reason

(1/2) > >>

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: ---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)
 
--- End code ---
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 :D
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.

Navigation

[0] Message Index

[#] Next page