-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ralf Mardorf schrieb: > * Good news > If the value for ulimit was set back to 0, than it's not possible > to set it again to another value, but this is possible again, > after the next startup.
yeah, I noticed this strange behaviour too. It's sufficient to close the shell and open another one. Of course, reboot fixes it too :-P > Core was generated by `./broken'. > Program terminated with signal 11, Segmentation fault. > [New process 3674] > #0 0x000000000040045f in main () > (gdb) where > #0 0x000000000040045f in main () > Current language: auto; currently asm > (gdb) quit > > Suse and 64 Studio create core files for "broken", it looks like > "qsynth" and "jackd" where killed because of an error, but without any > error. It might be impossible to get a core file. On the off chance that > I'll get a core file, did I used gdb correctly? yes, all done correctly. You did run qsynth and jackd from a terminal on which you set the ulimit -c unlimited prior to running them? But didn't get a core dump? Then indeed it looks as if they got killed by a signal or it could be an emergency shutdown triggered from within the applications. Anyway, if an program actually crashes (segmentation fault or similar), you should get an core file. If this isn't the case, I'd report this behaviour and just ask the autor(s) how to proceed or what additional informations they need. > For a bug report I would copy everything between "(gdb) where" and > "(gdb) quit" and nothing else, right? I don't need to attach the core > file, but I need to keep it, if I get a request to run gdb with other > options, is this correct? Yes, just the callstack info is sufficient. In this small test example, the stacktrace obviously lists just the main() function, because the null pointer error in this example happens in the second line within main(). In a real world example, such a stacktrace could be several hundred lines of text. Well, if the crash is sufficiently reproducible, you can even delete the core, if disk space is an concern, but it could be a good idea to keep it around. Indeed, using the core file, it's possible to look for additional informations like the contents of some variables. Cheers, Hermann -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJMj75ZbZrB6HelLIRAl1fAKCjLrljxFLsERpy3e0HlBzMnFGgCACgjta6 QWlMHNygg0s/85lPiihU7kA= =IxUT -----END PGP SIGNATURE----- _______________________________________________ 64studio-users mailing list [email protected] http://lists.64studio.com/mailman/listinfo/64studio-users
