KarenRei Report post Posted May 9, 2007 Beaverhunter: All this means is that it's *another* crash. The destructor itself couldn't have been the cause of the crash that matters -- the one that takes people out in-game, and the one that I'm focused on finding. One person using the CVS client reported it just last night. If they're available, I'll meet up with them this evening. Share this post Link to post Share on other sites
freeone3000 Report post Posted May 11, 2007 (gdb) start Breakpoint 1 at 0x80a12c8: file main.c, line 224. Starting program: /home/james/develop/elc/el.x86.linux.bin Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1229236496 (LWP 30072)] [Switching to Thread -1229236496 (LWP 30072)] main (argc=1, argv=0xbfafca04) at main.c:224 224 gargc=argc; (gdb) continue Continuing. *** glibc detected *** /home/james/develop/elc/el.x86.linux.bin: free(): invalid pointer: 0x0ba50d20 *** ======= Backtrace: ========= /lib/libc.so.6[0xb7a7f15e] /lib/libc.so.6(cfree+0x90)[0xb7a827b0] /home/james/develop/elc/el.x86.linux.bin[0x80da396] /home/james/develop/elc/el.x86.linux.bin[0x80d9931] /home/james/develop/elc/el.x86.linux.bin[0x8095466] /home/james/develop/elc/el.x86.linux.bin[0x80a12ec] /lib/libc.so.6(__libc_start_main+0xdc)[0xb7a2cebc] /home/james/develop/elc/el.x86.linux.bin[0x804e571] ======= Memory map: ======== 08048000-081a1000 r-xp 00000000 03:01 3932300 /home/james/develop/elc/el.x86.linux.bin 081a1000-081a3000 rw-p 00159000 03:01 3932300 /home/james/develop/elc/el.x86.linux.bin 081a3000-0ba94000 rw-p 081a3000 00:00 0 [heap] b6a00000-b6a21000 rw-p b6a00000 00:00 0 b6a21000-b6b00000 ---p b6a21000 00:00 0 b6b54000-b6bb8000 rw-p b6b54000 00:00 0 b6bb8000-b6bbd000 r-xp 00000000 03:01 590018 /usr/lib/libgpm.so.1.19.6 b6bbd000-b6bbe000 rw-p 00004000 03:01 590018 /usr/lib/libgpm.so.1.19.6 b6bbe000-b6c4f000 r-xp 00000000 03:01 737552 /lib/libslang.so.2.0.7 b6c4f000-b6c5e000 rw-p 00091000 03:01 737552 /lib/libslang.so.2.0.7 b6c5e000-b6c7d000 rw-p b6c5e000 00:00 0 b6c7d000-b6cb5000 r-xp 00000000 03:01 737488 /lib/libncurses.so.5.5 b6cb5000-b6cbd000 rw-p 00038000 03:01 737488 /lib/libncurses.so.5.5 b6cbd000-b6cbf000 rw-p b6cbd000 00:00 0 b6cbf000-b6cd4000 r-xp 00000000 03:01 591084 /usr/lib/libICE.so.6.3.0 b6cd4000-b6cd5000 rw-p 00014000 03:01 591084 /usr/lib/libICE.so.6.3.0 b6cd5000-b6cd7000 rw-p b6cd5000 00:00 0 b6cd7000-b6cdf000 r-xp 00000000 03:01 589836 /usr/lib/libSM.so.6.0.0 b6cdf000-b6ce0000 rw-p 00007000 03:01 589836 /usr/lib/libSM.so.6.0.0 b6ce0000-b6ce7000 r-xp 00000000 03:01 737664 /lib/librt-2.5.so b6ce7000-b6ce9000 rw-p 00006000 03:01 737664 /lib/librt-2.5.so b6ce9000-b6ced000 r-xp 00000000 03:01 591011 /usr/lib/libXdmcp.so.6.0.0 b6ced000-b6cee000 rw-p 00003000 03:01 591011 /usr/lib/libXdmcp.so.6.0.0 b6cee000-b6cf0000 r-xp 00000000 03:01 589917 /usr/lib/libXau.so.6.0.0 b6cf0000-b6cf1000 rw-p 00001000 03:01 589917 /usr/lib/libXau.so.6.0.0 b6cf1000-b6cf2000 rw-p b6cf1000 00:00 0 b6cf2000-b6cf6000 r-xp 00000000 03:01 590123 /usr/lib/libogg.so.0.5.3 b6cf6000-b6cf7000 rw-p 00003000 03:01 590123 /usr/lib/libogg.so.0.5.3 b6cf7000-b6d04000 r-xp 00000000 03:01 590007 /usr/lib/libXext.so.6.4.0 b6d04000-b6d05000 rw-p 0000c000 03:01 590007 /usr/lib/libXext.so.6.4.0 b6d05000-b6d06000 r-xp 00000000 03:01 638992 /usr/lib/tls/libnvidia-tls.so.1.0.8774 b6d06000-b6d07000 rw-p 00000000 03:01 638992 /usr/lib/tls/libnvidia-tls.so.1.0.8774 b6d07000-b7496000 r-xp 00000000 03:01 589840 /usr/lib/libGLcore.so.1.0.8774 b7496000-b74c6000 rwxp 0078f000 03:01 589840 /usr/lib/libGLcore.so.1.0.8774 b74c6000-b74ca000 rwxp b74c6000 00:00 0 b74ca000-b74cb000 rw-p b74ca000 00:00 0 b74cb000-b74de000 r-xp 00000000 03:01 737673 /lib/libpthread-2.5.so b74de000-b74e0000 rw-p 00012000 03:01 737673 /lib/libpthread-2.5.so b74e0000-b74e2000 rw-p b74e0000 00:00 0 b74e2000-b74f0000 r-xp 00000000 03:01 590584 /usr/lib/libcucul.so.0.99.0 b74f0000-b755b000 rw-p 0000e000 03:01 590584 /usr/lib/libcucul.so.0.99.0 b755b000-b755f000 rw-p b755b000 00:00 0 b755f000-b7566000 r-xp 00000000 03:01 590379 /usr/lib/libcaca.so.0.99.0 b7566000-b7567000 rw-p 00006000 03:01 590379 /usr/lib/libcaca.so.0.99.0 b7567000-b757f000 r-xp 00000000 03:01 590402 /usr/lib/libaa.so.1.0.4 b757f000-b7581000 rw-p 00018000 03:01 590402 /usr/lib/libaa.so.1.0.4 b7581000-b7582000 rw-p b7581000 00:00 0 b7582000-b75d2000 r-xp 00000000 03:01 590571 /usr/lib/libvga.so.1.4.3 b75d2000-b75d9000 rw-p 00050000 03:01 590571 /usr/lib/libvga.so.1.4.3 b75d9000-b75e2000 rw-p b75d9000 00:00 0 b75e2000-b75f0000 r-xp 00000000 03:01 590060 /usr/lib/libdirect-0.9.so.25.0.0 b75f0000-b75f1000 rw-p 0000d000 03:01 590060 /usr/lib/libdirect-0.9.so.25.0.0 b75f1000-b75f2000 rw-p b75f1000 00:00 0 b75f2000-b75f7000 r-xp 00000000 03:01 590480 /usr/lib/libfusion-0.9.so.25.0 Program received signal SIGABRT, Aborted. 0xb7a40d86 in raise () from /lib/libc.so.6 (gdb) bt full #0 0xb7a40d86 in raise () from /lib/libc.so.6 No symbol table info available. #1 0xb7a425b1 in abort () from /lib/libc.so.6 No symbol table info available. #2 0xb7a772db in ?? () from /lib/libc.so.6 No symbol table info available. #3 0x00000009 in ?? () No symbol table info available. #4 0xbfafc0c0 in ?? () No symbol table info available. #5 0x00000400 in ?? () No symbol table info available. #6 0x00000000 in ?? () No symbol table info available. Karen, I think I found your mysterious error. (This is *with* the most recent Makefile.linux, no clue why debugging symbols arn't showing up) Share this post Link to post Share on other sites
KarenRei Report post Posted May 11, 2007 As has been stated each time, I need either a valid stacktrace (with files and line numbers) or a way to reproduce this. Share this post Link to post Share on other sites
Beaverhunter Report post Posted May 11, 2007 (edited) Still haven't had a crash in game to be able to debug. Is there no clue whatsoever what can cause this crash? Fighting? Harvesting? Idling? Is there no correlation between what the users have reported when they crashed? Also maybe offtopic but can you commit/change this: init.c(246) : error C2065: 'd' : undeclared identifier Someone changed init.c at those lines and added a "closedir(d)" without having #ifndef WINDOWS first, which means the d got defined inside one of those just for linux but it is not defined for windows. Edited May 11, 2007 by Beaverhunter Share this post Link to post Share on other sites
WildIce Report post Posted May 11, 2007 Still haven't had a crash in game to be able to debug. Is there no clue whatsoever what can cause this crash? Fighting? Harvesting? Idling? Is there no correlation between what the users have reported when they crashed? for myself, i only had crashes while i was fighting with this new client, and pretty much of them Share this post Link to post Share on other sites
KarenRei Report post Posted May 11, 2007 (edited) Well, Max12 (who says e has a reliable way to reproduce it, and is using the CVS client) is supposed to meet up with me tonight... so hopefully we'll be able to get this figured out. Edited May 11, 2007 by KarenRei Share this post Link to post Share on other sites
KarenRei Report post Posted May 12, 2007 Scratch that -- it only crashes on his work computer, which he can't use Share this post Link to post Share on other sites
bluap Report post Posted May 12, 2007 KarenRei, sorry slightly off topic but you said before you don't check the other forums much so you may have missed this. Can't have you missing praise Share this post Link to post Share on other sites
Beaverhunter Report post Posted May 12, 2007 ... for myself, i only had crashes while i was fighting with this new client, and pretty much of them Well then maybe you want to tell us what you were fighting? And when? And with CVS? Or with the client Ent posted? Any special circumstances? Any special day? More info would be nice=D Also keep fighting!! And report every crash and answer the above questions, and if you compile yourself, try and use Debug version from compiler so you can make stacktraces and get useful info. Maybe you even get a thumbs up from KarenRei if you do;D Share this post Link to post Share on other sites
KarenRei Report post Posted May 12, 2007 That'd be a very big thumbs-up. Also, PM hyekyet around 10:30 CST tonight; I'm going to try to get a group together to fight and see if we can reproduce this crash. Thanks, bluap -- I missed that Share this post Link to post Share on other sites
KarenRei Report post Posted May 13, 2007 Okay, nobody showed up. Really, we need to get people together at some point to try and reproduce this crash... Share this post Link to post Share on other sites
freeone3000 Report post Posted May 13, 2007 Okay. Crashes. It crashes on startup. Both accounts, numerous places, by which I can extend any place (on Seridia, at least). Places tried: isla prima near campfire, just north of the bridge, Morcraven marsh at raven, winery, and tree mushrooms, tarseengaard storage, and red quartz area. Is this reproducable enough? Share this post Link to post Share on other sites
Beaverhunter Report post Posted May 13, 2007 If more than 1 were crashing on startup we would see 100s of posts flooding the area, so it's not reproduceable. I have tried to fight brownies, wood sprites and leopards for some hour now at Hurquin, with newest CVS and debug client on test server... no crash... so let's call that one not reproduceable aswell. Fighting cyclops I cannot do, someone else has to try that. Share this post Link to post Share on other sites
ttlanhil Report post Posted May 13, 2007 If more than 1 were crashing on startup we would see 100s of posts flooding the area, so it's not reproduceable.it's a crash. he can reproduce it on demand. that defines a reproduceable crash.it doesn't have to affect a hundred people to be valid as for causes of crashes, I had a couple when I was fighting ogres in a cave yesterday, the trace info mentioned cal3d and I think something about core animations, however ogres are dangerous to me, and I didn't want to take any longer than I had to getting back in the game... so no backtrace to pick over. another note, I do have the 'enable blood' option on... and based on the above, I wonder if there's some cal3d calls that aren't safe? I'll try hunting them again some time (maybe tomorrow, maybe the day after, depending on time available) and see if I can capture a backtrace Share this post Link to post Share on other sites
Beaverhunter Report post Posted May 13, 2007 (edited) freeones crash is most likely related to that shadow bug that was around before, but that he started to have it again now seems weird. He should try and log in while inside a storage or alike, if he doesn't crash then... then it's the old shadow bug that was suppose to be fixed. I would say everything points to Cal3d to being a problem. Since crashes only seems to occur when people fight, that is interacting with actors, which Cal3d handles... that must have something to do with it. Was something changed when the "dragon missed one attack animation"-bug got "fixed"? Also with the client ent posted, how was the "custom" cal3d.dll compiled? Who compiled it? Maybe it needs to be independantly compiled for some reason in some cases... At least it should be considered compiling another version... Also what about release/debug version? If some libraries were compiled in debug version, no wonder ppl are getting slow downs on the FPS. Also why not move up to the newest Cal3d version instead of the old one? I pretty much never had a single crash with CVS. And not that many ppl report crashes, so is it really bigger crash rate than it was before all these updates? I do however since some day ago sometimes/rarely get a Memory access violation error on EL client exit, no crash or ability to debug, but it just said that it couldn't move a certain memory area to another. (Happened last time yesterday or day before, after long time play) Edited May 13, 2007 by Beaverhunter Share this post Link to post Share on other sites
crusadingknight Report post Posted May 13, 2007 (edited) I would say everything points to Cal3d to being a problem. Since crashes only seems to occur when people fight, that is interacting with actors, which Cal3d handles... that must have something to do with it. Was something changed when the "dragon missed one attack animation"-bug got "fixed"? Also with the client ent posted, how was the "custom" cal3d.dll compiled? Who compiled it? Maybe it needs to be independantly compiled for some reason in some cases... At least it should be considered compiling another version... Also what about release/debug version? If some libraries were compiled in debug version, no wonder ppl are getting slow downs on the FPS. The entire Cal3D interface seems to be unchanged, with the only additions being a new argument, and a call to the timer to fix animation cycling, neither of which seems t have anything capable of causing memory corruption. Compilation for libraries aren't debug or any such thing, not would it really make a difference as very few people have EL run at 100% CPU. After all, if this crash is in Cal3D, why aren't there any backtraces showing it? Cal3D has a very finite codepath, so such a bug should already have been apparent in the last version. Plus, I seem to recall people compiling their own clients have this crash, and they're hardly using a custom library. Given the codebase for the client, I suspect that it is more likely a memory handling problem somewhere in the code, rather than a bug in the much simpler Cal3D. Edited May 13, 2007 by crusadingknight Share this post Link to post Share on other sites
KarenRei Report post Posted May 13, 2007 Freeone3000: Platform? Coordinates? Time of day? Version of client? Share this post Link to post Share on other sites
ttlanhil Report post Posted May 13, 2007 freeones crash is most likely related to that shadow bug that was around before, but that he started to have it again now seems weird. He should try and log in while inside a storage or alike, if he doesn't crash then... then it's the old shadow bug that was suppose to be fixed.maybe. either way it needs to be fixedI would say everything points to Cal3d to being a problem. Since crashes only seems to occur when people fight, that is interacting with actors, which Cal3d handles... that must have something to do with it.please don't say that, at least until you understand code well enough that you can be certain. Far more likely the way we use cal3d or the data files or something are the problemAlso with the client ent posted, how was the "custom" cal3d.dll compiled? Who compiled it? Maybe it needs to be independantly compiled for some reason in some cases... At least it should be considered compiling another version... Also what about release/debug version? If some libraries were compiled in debug version, no wonder ppl are getting slow downs on the FPS.most likely as with all previous releases since we switched to cal3d. probably ent, roja, or learner. no it doesn't. forget about the debug/realease thing, that's MSVC only, and most people don't use that.no, debug does not necessarily slow anything down (most people using CVS are on debug. and it's needed to get info when something goes wrong) Also why not move up to the newest Cal3d version instead of the old one?because the one we have works, and its interface is what ELC was coded toI pretty much never had a single crash with CVS. And not that many ppl report crashes, so is it really bigger crash rate than it was before all these updates?I do however since some day ago sometimes/rarely get a Memory access violation error on EL client exit, no crash or ability to debug, but it just said that it couldn't move a certain memory area to another. (Happened last time yesterday or day before, after long time play) memory access violation generally is a cause of a crash Share this post Link to post Share on other sites
freeone3000 Report post Posted May 13, 2007 More specific info on the crash-on-startup problem. it crashes IMMEDIATLY after I type 'gdb ./el.x86.linux.bin' (or just ./el.x86.linux.bin), no window shown, no login screen, at all. Ttl thinks it may be a problem with a library mismatch, but I updated, restarted (there goes my uptime), and 'make clean' with 'cvs up -d' as of the time I'm writing this post. Same crash (with different memory addresses). Is there a null pointer somewhere? Share this post Link to post Share on other sites
KarenRei Report post Posted May 14, 2007 Crash in gdb? So you have a stacktrace? Post it Share this post Link to post Share on other sites
freeone3000 Report post Posted May 15, 2007 That *is* my stacktrace. Even with compiled with -g/-ggdb, it does not give filenames/line numbers, just mem addresses, which are useless. Before, it complains about not loading a valid image file. Share this post Link to post Share on other sites
Alia Report post Posted May 15, 2007 That *is* my stacktrace. Even with compiled with -g/-ggdb, it does not give filenames/line numbers, just mem addresses, which are useless. Before, it complains about not loading a valid image file. Look at your linking options, maybe you have -s or -S option turned on (strip symbols/debug symbols). Share this post Link to post Share on other sites
freeone3000 Report post Posted May 16, 2007 No, nothing of the sort found... Anything else that could have caused it? (Command: grep -i Makefile.linux -e -s) Share this post Link to post Share on other sites
Florian Report post Posted May 17, 2007 As my post are completely ignored in the RC client thread, I'll post here again: Win32 RC Client crashes for no apparent reason. MS VC debugger offers no stack trace, but disassembled code and the crash position. Is that any help? Share this post Link to post Share on other sites
KarenRei Report post Posted May 17, 2007 No, that would be no help. Crashes are known and widely reported; your post was "just another one", which is probably why it took no special notice. Crash fixing work is underway. Share this post Link to post Share on other sites