Re: [Warzone-dev] exception dump problems?
Am Freitag, 2. März 2007 schrieb Ari Johnson: On 2/26/07, Dennis Schridde [EMAIL PROTECTED] wrote: Am Sonntag, 25. Februar 2007 schrieb Giel van Schijndel: [EMAIL PROTECTED] schreef: I can not even reads the text that should be in Warzone crashed unexpectedly, would you like to save a diagnostic file? When it crash. I just get a bunch of sqaure characters. Another problem is it is hardcoded to use c:\temp even if there is no c:\temp! Then I assume I get message of Failed to create dump file but I can not reads this either, it shows square blocks for text again. This is windows with compiler VS2005. It uses the temp directory from my profile on my pc (e.g. docs settings/user/local settings/temp) Yes, C:\temp is just a fallback... Maybe we need to improve this... Per default it should use GetTempPath(), which should be present on nearly any Windows version. --Dennis Can you add some code to check for availability of this in configure? execinfo.h is not available on the Mac, so Warzone won't build on the Mac anymore (not even 2.0.x). Sure. I could add some HAVE_EXECINFO_H define, probably. Another way would be to add a 3rd codepath to lib/framework/exceptionhandler.c to handle MacOS. (Even an empty path would be possible as a workaround.) execinfo.h should be present on all GNU systems (Linux or Arch is what I know of) running glibc. If BSD also uses glibc, then it should work there too. --Dennis pgpLdA54S76Cl.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] How to read the exception dump?
Am Sonntag, 25. Februar 2007 schrieb Per Inge Mathisen: I miss some documentation for the recently added exception handler. Most importantly, how can I read the binary dump file? - Per PS Why not dump it as a text file? Now done. For further changes: The 1st (and 2nd) entry in the backtrace list should not be skipped, as it is afaik the only possibility to find out whether the given return addresses are valid for a given binary. (Just check whether addr2line of the 1st address matches the position of the call to backtrace() in lib/framework/exceptionhandler.c.) --Dennis pgpLHVrmGk3sD.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] revision 824 Patch for screen.c?
Am Freitag, 2. März 2007 schrieb Per Inge Mathisen: On 3/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Before the hardcode of 512, it was change to BACKDROP_HACK_WIDTH, and BACKDROP_HACK_HEIGHT (which still is 512). In code below this with glBegin(GL_TRIANGLE_STRIP); glTexCoord2f(0, 0); glVertex2f(0, 0); glTexCoord2f(255, 0); glVertex2f(screenWidth, 0); glTexCoord2f(0, 255); glVertex2f(0, screenHeight); glTexCoord2f(255, 255); glVertex2f(screenWidth, screenHeight); glEnd(); should not the 255 be also changed? Why is it 255 in first place? if BACKDROP_HACK_HEIGHT = 1024, then it no look right ? Anybody explain why this value used? I think it is mistake? I believe those are texture coordinates that get translated into 0.0f - 1.0f. Although I must admit I am a bit mystified about how exactly this works. I have no idea, either. I tried to change it to 0.0f/1.0f a while ago, but it didn't look too nice. (Stretched much too much.) --Dennis pgpW1JhI4SNFb.pgp Description: PGP signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] NSIS commandline define problem
Am Freitag, 16. Februar 2007 schrieb Giel van Schijndel: Dennis Schridde schreef: Am Freitag, 16. Februar 2007 schrieb Giel van Schijndel: Dennis Schridde schreef: Author: devurandom Date: Thu Feb 15 16:36:25 2007 New Revision: 757 URL: http://svn.gna.org/viewcvs/warzone?rev=757view=rev Log: Port of r756 (buildsystem/installation improvements) Modified: trunk/Makefile.am trunk/autopackage/default.apspec.in trunk/configure.ac trunk/data/Makefile.am trunk/nsis/Makefile.am trunk/nsis/Makefile.raw trunk/win32/Makefile.am The changes you've made here to trunk/nsis/Makefile.raw (changing the define params from /Dvar=val to -Dvar=val) invalidate the command line on windows. Simply reverting those changes make it work again. So, my question, are you sure these changes are necessary for something? I wouldn't have done it if it wouldn't be necessary... makensis wants -D on Linux and /D on Windows, apparently... I have no idea why the NSIS team decided on that, it's very ugly IMHO... I thought, if it would read -D on Linux, it might take the same on Windows. I filed a bug on NSIS: http://sourceforge.net/tracker/index.php?func=detailaid=1661503group_id =22049atid=373085 Bug has been fixed, '-' will be allowed as option on Windows in NSIS 2.24 (?). Files starting with a slash can be escaped via '--' like it is done on Linux allready. --Dennis pgpV0pa4r2X6v.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/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
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] exception dump problems?
On 3/3/07, Dennis Schridde [EMAIL PROTECTED] wrote: If BSD also uses glibc, then it should work there too. I never used *BSD, but I am pretty sure they do not use glibc. - 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?
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
[Warzone-dev] GNA site too busy? (Malformed network data)
I have bad luck. Everytime I try to do update or show log, I get Malformed network data error. That is bad error name for server too busy :( Was this reason why move from berlios? https://mail.gna.org/public/help/2006-02/msg00097.html When the server load reach a certain point, svnserve requests are off. Then only anonymous download is only possible via http. Is GNA reply. -- Click for dental plans with huge savings, top service and coverage http://tagline.hushmail.com/fc/CAaCXv1KbKvUVl8pTmTsFeEkk6Iuru89/ ___ 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
[Warzone-dev] patch 835 is not right?
The patch in 835 which is (i think),
pimemode.c:void pie_ScreenFlip(CLEAR_MODE clearMode)
if (screen_GetBackDrop()) { screen_Upload(NULL);}
Is wrong.
This breaks shadows backdrops. You can tell instant at CAM_3A.
I can not check if loop.c is wrong, GNA is too busy and can not do
diff!
:(
Took 1 hour to get 836, and still gets the 'server too busy' error
(malforned data network) message. :( :( :( !
--
Click to view our discounts on helmets - motorcycles, bikes, or snow sports
http://tagline.hushmail.com/fc/CAaCXv1UyEXyOaNOJuUfkQSyNNLtSDkh/
___
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=22429view=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] Approaching Version 2.0.6
i have just about completed the updating of the manual... a few more pages to do... as soon as i have completed them i will delete the old file and upload the new one. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Approaching Version 2.0.6
will be plain ordinary html ( through ms frontpage - version 2003) in a zip file. will be approximately 75mb... give or take a few mb. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
