Jump to content
Eternal Lands Official Forums
Entropy

Special effects

Recommended Posts

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

(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. :P (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

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 by Beaverhunter

Share this post


Link to post
Share on other sites

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 :P

Share this post


Link to post
Share on other sites

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 by KarenRei

Share this post


Link to post
Share on other sites

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 :confused:

Share this post


Link to post
Share on other sites

...

for myself, i only had crashes while i was fighting with this new client, and pretty much of them :P

 

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

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 :omg:

Share this post


Link to post
Share on other sites

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

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
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

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 by Beaverhunter

Share this post


Link to post
Share on other sites

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 by crusadingknight

Share this post


Link to post
Share on other sites
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 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.
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 problem
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.
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 to
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)

memory access violation generally is a cause of a crash

Share this post


Link to post
Share on other sites

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

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

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

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

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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×