Re: [Warzone-dev] gdmps in 2.0?
I think the xdg-mail app in http://portland.freedesktop.org/wiki/ is supposed to solve the problem of how to send email from an application. But how it could deal with people like me who uses gmail over http and pine over ssh, I do not know. I doubt it can. I suspect many today use webmail and simply do not have any mail configured on their local computer. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] gdmps in 2.0?
Am Sonntag, 4. März 2007 schrieb Christian Ohm: > On Sunday, 4 March 2007 at 0:22, Per Inge Mathisen wrote: > > On 3/4/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: > > >So what do you think should be done? > > >Leave it as is (was before my commits) and don't try to automate the > > >backtrace > > >creation? Or offer a way to assist unexperienced users to create a > > >backtrace? > > >If yes, how? > > > > I don't know. The linux backtrace stuff that is in now is not very > > helpful. I think if we could generate a backtrace with gdb and make it > > ready to send to us somehow, that would be great. Let me do some very > > quick and dirty thinking aloud: > > > > * During ./configure (or whatever) we find the path to gdb and an > > email app, and write that into a "wz2100" script that we generate from > > a "wz2100.in" template. > > Why? If gdb is in the path, you don't need the full directory, and if > it's not, how do you want to find it? > > > * Instead of starting the C binary directly, we run it through the > > wz2100 script generated above, which sets ulimit to produce core > > dumps, and checks for a core dump already produced, and if there is > > one, offers to send an anonymous backtrace from it to some email > > address we use for collecting them. It can also grab some system data > > to send from various sources (uname? /proc?). > > Sounds like the wrapper script I sent a while ago: > https://mail.gna.org/public/warzone-dev/2007-02/msg00229.html > That seems like the easiest method, but you can also set up the signal > handler to run gdb on a crash, see for example > http://svn.mplayerhq.hu/mplayer/trunk/mplayer.c?revision=22429&view=markup > (search for exit_signalhandler, last part of the function). The wrapper > script seems easier and more flexible, though. This implementation has one flaw: snprintf(spid, 19, "%i", getpid()); *printf's behaviour is afaik undefined after receiving a signal. And they only start gdb, but don't use it to dump anything. That's a start, but not exactly what we wanted... > > I do not know of a good way to direct core dumps to a specific > > location, where we know to find it, or what is a good crossplatform > > http://www.die.net/doc/linux/man/man5/core.5.html says: "By default, a > core dump file is named core, but the /proc/sys/kernel/core_pattern file > (new in Linux 2.5) can be set to define a template that is used to name > core dump files." But changing that file needs root access, so that's > not very practical. > > > way of sending email from unix-likes, though. Also we must find a way > > man mail. If gdb is available, mail should be, as well. If it's not, > jsut ask the user to send the file himself. Eg. on my system "mail" is not available, as I said earlier... > > for this script to interact nicely if it is started from a GUI menu > > instead of from a command-line - I do not know how hard this is, I am > > a hardcore command-line junkie and hardly ever use those fancy menu > > things. pgp7CrYSHSul3.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] gdmps in 2.0?
On Sunday, 4 March 2007 at 0:22, Per Inge Mathisen wrote: > On 3/4/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: > >So what do you think should be done? > >Leave it as is (was before my commits) and don't try to automate the > >backtrace > >creation? Or offer a way to assist unexperienced users to create a > >backtrace? > >If yes, how? > > I don't know. The linux backtrace stuff that is in now is not very > helpful. I think if we could generate a backtrace with gdb and make it > ready to send to us somehow, that would be great. Let me do some very > quick and dirty thinking aloud: > > * During ./configure (or whatever) we find the path to gdb and an > email app, and write that into a "wz2100" script that we generate from > a "wz2100.in" template. Why? If gdb is in the path, you don't need the full directory, and if it's not, how do you want to find it? > * Instead of starting the C binary directly, we run it through the > wz2100 script generated above, which sets ulimit to produce core > dumps, and checks for a core dump already produced, and if there is > one, offers to send an anonymous backtrace from it to some email > address we use for collecting them. It can also grab some system data > to send from various sources (uname? /proc?). Sounds like the wrapper script I sent a while ago: https://mail.gna.org/public/warzone-dev/2007-02/msg00229.html That seems like the easiest method, but you can also set up the signal handler to run gdb on a crash, see for example http://svn.mplayerhq.hu/mplayer/trunk/mplayer.c?revision=22429&view=markup (search for exit_signalhandler, last part of the function). The wrapper script seems easier and more flexible, though. > I do not know of a good way to direct core dumps to a specific > location, where we know to find it, or what is a good crossplatform http://www.die.net/doc/linux/man/man5/core.5.html says: "By default, a core dump file is named core, but the /proc/sys/kernel/core_pattern file (new in Linux 2.5) can be set to define a template that is used to name core dump files." But changing that file needs root access, so that's not very practical. > way of sending email from unix-likes, though. Also we must find a way man mail. If gdb is available, mail should be, as well. If it's not, jsut ask the user to send the file himself. > for this script to interact nicely if it is started from a GUI menu > instead of from a command-line - I do not know how hard this is, I am > a hardcore command-line junkie and hardly ever use those fancy menu > things. -- BOFH excuse #246: It must have been the lightning storm we had (yesterday) (last week) (last month) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] gdmps in 2.0?
Am Sonntag, 4. März 2007 schrieb Per Inge Mathisen: > On 3/4/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: > > So what do you think should be done? > > Leave it as is (was before my commits) and don't try to automate the > > backtrace creation? Or offer a way to assist unexperienced users to > > create a backtrace? If yes, how? > > I don't know. The linux backtrace stuff that is in now is not very > helpful. I think if we could generate a backtrace with gdb and make it > ready to send to us somehow, that would be great. Let me do some very > quick and dirty thinking aloud: > > * During ./configure (or whatever) we find the path to gdb and an > email app, and write that into a "wz2100" script that we generate from > a "wz2100.in" template. > > * Instead of starting the C binary directly, we run it through the > wz2100 script generated above, which sets ulimit to produce core > dumps, and checks for a core dump already produced, and if there is > one, offers to send an anonymous backtrace from it to some email > address we use for collecting them. It can also grab some system data > to send from various sources (uname? /proc?). We could check $? for the return status... And on error zip up the coredump and ask the user to send it to us. I think it will be hard to send it via email directly, since there is no standard way of sending mails on Linux systems. Some systems have "mail", but it may not be setup correctly (From-address, email-gateway, etc.), while most systems probably haven't got that kind of program at all. And writing scripts to detect KDE, Gnome, and whatnot is probably not easy either. So I think just giving the user a notice to please send us that file is the best and easiest solution. The problem with that is of course that it doesn't work if the user starts wz from a menu. In that case we would need to pop up some tiny textbox. KDE offers a small commandline utility named "kdialog", which can display a textbox, or yes/no buttons and all that. I think it's getting hairy now... > I do not know of a good way to direct core dumps to a specific > location, where we know to find it, or what is a good crossplatform > way of sending email from unix-likes, though. Also we must find a way > for this script to interact nicely if it is started from a GUI menu > instead of from a command-line - I do not know how hard this is, I am > a hardcore command-line junkie and hardly ever use those fancy menu > things. Coredumps are afaik in the "current directory", wherever that is... But probably, if we don't chdir too much, the directory the startup script is running from should be the same that Warzone is running in. > > As I said, this is just some thinking aloud... What I am currently thinking about: On error signal create a pipe and run a command similar to this: gdb argv[0] getpid() Now push commands like "backtrace full" through the pipe and dump the output we recieve into a file. pgpSgGWuLC4py.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] gdmps in 2.0?
On 3/4/07, Dennis Schridde <[EMAIL PROTECTED]> wrote: So what do you think should be done? Leave it as is (was before my commits) and don't try to automate the backtrace creation? Or offer a way to assist unexperienced users to create a backtrace? If yes, how? I don't know. The linux backtrace stuff that is in now is not very helpful. I think if we could generate a backtrace with gdb and make it ready to send to us somehow, that would be great. Let me do some very quick and dirty thinking aloud: * During ./configure (or whatever) we find the path to gdb and an email app, and write that into a "wz2100" script that we generate from a "wz2100.in" template. * Instead of starting the C binary directly, we run it through the wz2100 script generated above, which sets ulimit to produce core dumps, and checks for a core dump already produced, and if there is one, offers to send an anonymous backtrace from it to some email address we use for collecting them. It can also grab some system data to send from various sources (uname? /proc?). I do not know of a good way to direct core dumps to a specific location, where we know to find it, or what is a good crossplatform way of sending email from unix-likes, though. Also we must find a way for this script to interact nicely if it is started from a GUI menu instead of from a command-line - I do not know how hard this is, I am a hardcore command-line junkie and hardly ever use those fancy menu things. As I said, this is just some thinking aloud... - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] gdmps in 2.0?
Am Samstag, 3. März 2007 schrieb Per Inge Mathisen: > I agree with Watermelon. I think there is a good reason why I can't > think of any other project that tries to do this. AFAICT, gnome uses > gdb to produce core dump reports. > > Stripping debug symbols is bad. IIRC, in most Linux distros, every > binary is shipped with debug symbols so that (power) users can produce > useful bug reports with gdb. > > On Windows, of course, things are rather different. I remember the > Windows error dump code in Freeciv used to produce some useful error > reports (but I think it is only used in the win32 client that hardly > anybody use anymore). Well, I didn't say that the Minidump should be removed. It allready was helpful in at least one case. So what do you think should be done? Leave it as is (was before my commits) and don't try to automate the backtrace creation? Or offer a way to assist unexperienced users to create a backtrace? If yes, how? --Dennis pgps1qB3GLY0e.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] gdmps in 2.0?
I agree with Watermelon. I think there is a good reason why I can't think of any other project that tries to do this. AFAICT, gnome uses gdb to produce core dump reports. Stripping debug symbols is bad. IIRC, in most Linux distros, every binary is shipped with debug symbols so that (power) users can produce useful bug reports with gdb. On Windows, of course, things are rather different. I remember the Windows error dump code in Freeciv used to produce some useful error reports (but I think it is only used in the win32 client that hardly anybody use anymore). - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] gdmps in 2.0?
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
