On 3/3/07, Dennis Schridde <[EMAIL PROTECTED]> wrote:
Hello everyone... I am not yet sure whether the inclusion of the gdmp code in brances/2.0 was a good idea... We probably need to first find out how to get usefull informations from the GLibC backtraces, what is most convenient for our users and so on. In the final release the gdmp should be helpful if the user is using the official binary. But if he is using a selfcompiled one (eg. Gentoo) it will very probably be completely useless as the return addresses don't match the one in my binary. In the trunk the backtrace is effectively useless, since all binaries are selfcompiled and the return addresses wont match the ones in the devs binary. I just experienced this on the forums: http://wz2100.net/forum/index.php?topic=472.0 His backtrace gives me a creation of the backtrace in ../src/structure.c:3964, certainly not the exceptionhandler... An option might be to extract the debuginfo of our own process using objcopy and dump it into a file and ask our users to send us this file. This would of course not work if the user has binutils not installed... (But at least in trunk compilations it might help a bit.) Another option to get a usefull backtrace is to call gdb using the system() function and dump it's output into a file... What do you think about this problem? --Dennis
I think the best/easiest option is to distribute debug binaries with limited optimization flags(like warzone.exe/.so for release,warzone_d.exe/.so for debug or sumthing)...so advanced users can help bug-hunting by using debug builds/providing backtrace with symbols at the costs of performance. In my opinion dump will be useless if user binaries(self-compiled) are not consistent with the ones we distribute like you said...dumps are only useful when a project has controls over binaries(closed source official binaries only)...
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
