Jump to content
Eternal Lands Official Forums
Wytter

Crash On Map Change

Recommended Posts

Crash on map change from WSC into diamond mine.

Ugh.. When is your CVS from?

Share this post


Link to post
Share on other sites

Also had a crash from coal mine to DP map.

Used (unmodified) CVS files from 27 december compiled with VC 6.

 

From windows event logs :

 

Application popup: Eternal Lands: elc.exe - Application Error : The instruction at "0x0041d699" referenced memory at "0x1069a6e8". The memory could not be "read".

 

Click on OK to terminate the program

Click on CANCEL to debug the program

Edited by teranoz

Share this post


Link to post
Share on other sites

No idea, I used the code as is (including the VC project files), only thing I changed was adding the timer files to the project, and turning off compile warnings in Release and Debug version.

 

How should I compile with those options in VC 6 (did not get it working in VC 2005)

Share this post


Link to post
Share on other sites

Try putting:

 

#define OPTIMIZED_LOCKS

#define POSSIBLE_FIX

 

In global.h

Share this post


Link to post
Share on other sites

Umm, then let me make this absolutely clear:

 

I ONLY want to hear about crashes happening with a CVS client from the last week AND it must be compiled with -DPOSSIBLE_FIX and -DOPTIMIZED_LOCKS.

Share this post


Link to post
Share on other sites

hello,

 

during the last several days, (I think it happened first on 23. or 24.12) my client disconnected unexpectedly. I'm not sure if this has something to do with the map change bug, but since it never happened before in this way, i decided to report it here.

 

The diconnection mostly happened immediately after a map change. Yesterday I exited pl storage and got disconnected. There are no resyncs or even lags right before, I just got the usual 'disconnected from server' message. One time it happened to me when somebody wanted to trade me. Just immediately after the yellow message show up, i got disconnected. This disconnections happen so fast, that I notice them only after 2 or 3 seconds. One time it happened to me during autowalk on pl map, but mostly it happens after map change.

 

This happened to me ~6-10 times since thursday or friday last week.

 

Is this of interest for you? If so, what can I do to help catching this down? In addition to the usually defined macros, I compile my client with -DDEBUG -DEXTRA_DEBUG and -DMUTEX_DEBUG defined.

I redirect the huge amount of output created by the -DMUTEX_DEBUG macro into a log file and most time I also log the raw connection data. So there are lots of log files that may help.

 

hth

Share this post


Link to post
Share on other sites

Are you sure that it is not caused by a lagging connection? I have not been able to reproduce connection errors here at least.

 

A good place to start would be the connection_log.txt. The cause of why it disconnected should be in one of the last messages, but since it happens so fast I'm not sure it'd give any useful information. Since it's binary data you'd normally have to use a hex editor to examine them. But I'll make a small program for examining the connection log instead :D

 

Are you running the latest SDL-libs?

 

Was there anything in the error_log.txt?

Edited by Wytter

Share this post


Link to post
Share on other sites

Here's the file for examining the data:

 

http://wytter.tfm.ro/elc/examine.c

 

I did not finish the:

char * get_actor_info(unsigned char * data)

char * get_stats_info(short * data)

char * get_trade_info(int type, unsigned char * data)

char * get_knowledge_info(int len, unsigned char * data)

char * get_items_info(unsigned char * data)

char * get_item_info(unsigned char *data)

char * get_teleporters_info(unsigned char * data)

char * get_bag_info(unsigned char * data)

char * get_response_info(unsigned char * data, int len)

char * get_active_spells_info(unsigned char * data)

 

Yet as I hope it won't be necissary :D

Edited by Wytter

Share this post


Link to post
Share on other sites
Are you sure that it is not caused by a lagging connection? I have not been able to reproduce connection errors here at least.

 

A good place to start would be the connection_log.txt. The cause of why it disconnected should be in one of the last messages, but since it happens so fast I'm not sure it'd give any useful information. Since it's binary data you'd normally have to use a hex editor to examine them. But I'll make a small program for examining the connection log instead :rolleyes:

 

Are you running the latest SDL-libs?

 

Was there anything in the error_log.txt?

 

No i'm not sure, that this is not because of a lagging connection. It just doesn't run like the connection were lagging. And after some of the disconnections I send ping commands to the server to check the connection. I usually doing this by sending 5-10 pings within a very short time to get an average out of them.

 

My sdl ist libsdl-1.2.7-r3 which is the latest stable release for my distro (using gentoo, my system is quite up to date, as I sync and update it once a day). There is release 1.2.8 available within the portage repository, but as it is still marked unstable I only want to upgrade to this version if this is really necessary. My SDL_net is relesease 1.2.5, which is the latest version available for gentoo.

 

I don't know if there was something in the error_log.txt file after the disconnections. That's my current error_log.txt after playing for ~2 hours this morning/noon:

 

Error: Problems loading texture: ./textures/fontv.bmp

Error: Problems loading texture: ./textures/particle0.bmp

Error: Problems loading texture: ./textures/particle1.bmp

Error: Problems loading texture: ./textures/particle2.bmp

Error: Problems loading texture: ./textures/particle3.bmp

Error: Problems loading texture: ./textures/particle4.bmp

Error: Problems loading texture: ./textures/particle5.bmp

Error: Problems loading texture: ./textures/particle6.bmp

Error: Problems loading texture: ./textures/particle7.bmp

Error: draw_scene.c.draw_scene:69 - OpenGL error 1284

Error: Unable to add command 23 - 61

Error: Unable to add command 25 - 1394

Error: Unable to add command 24 - 1394

Error: draw_scene.c.draw_scene:69 - OpenGL error 1284

Error: Unable to add command 24 - 1394

Error: draw_scene.c.draw_scene:69 - OpenGL error 1284

 

 

I've seen those opengl errors appearing before (not sure which error numbers though) and the errors about the missing particles first appeared yesterday or maybe on tuesday after syncing elc with CVS and recompiling.

 

Thank you much for this examince app. I ran my current connection_log.txt through it, but didn't find any interesting, but it didn't crash either during my last playtime. Can I use examine in a way like this?

./examine `tail -f ~/.elc/connection_log.txt`

or won't this produce any meaningful results? I just will try it. :rolleyes:

 

Should it happen again, I will not reconnect immediately, but rather shut down the client and take a look at the logs.

 

Thanks

Share this post


Link to post
Share on other sites

Well, it wouldn't create meaningful results, as I designed it to just open the file given by $1. But it could be done without too many modifications - just don't have the time today or tomorrow, but feel free to modify it - it's public domain.

Share this post


Link to post
Share on other sites

Actually im crashing not when changing maps, but sometimes after logging in.

 

When i manage it to catch this crash in GDB and typed "where" i got only a lot of question marks and an address reported in libGLcore.so.1.

 

Piper

Share this post


Link to post
Share on other sites

Hmm, that sounds like a missing check_gl_errors(); call. Is probably your library acting up...

 

Anyway, I think I'll merge this - seems to be working as it should...

Share this post


Link to post
Share on other sites

OK, removed the #define's and made OPTIMIZED_LOCKS and POSSIBLE_FIX the normal target.

Share this post


Link to post
Share on other sites

Anyway it is still there. I am using yesterday's CVS and client crashed when I used ring to Portland.

 

Regards.

Share this post


Link to post
Share on other sites

I added a small fix about 2 hours ago, that should work... Was related to inaccurate checking of whether the current actor became a null-pointer after getting a server message... I am 100% sure that was the bug you ran into.

Edited by Wytter

Share this post


Link to post
Share on other sites

Well I've compiled newest CVS and for hello I got a segfault (when it starts). Here is what strace told me:

shmdt(0x40e55000) = 0

write(6, "\217\24T\0\1\0\0\0\3\0\0\0?\1\0\0GL_EXT_texture_o"..., 348) = 348

read(6, "\1\1\22\0\0\0\0\0\5\0\0\2\0\0\0\0\0\0\0\0\1\0\0\0P/Q\10"..., 32) = 32

shutdown(6, 2 /* send and receive */) = 0

close(6) = 0

ioctl(7, 0xc0104629, 0xbffff32c) = 0

write(15, "@j\v@\2\0\0\0\3\0\0\0\20R\1@\340V\1@h\242\"@@\247\"@\320"..., 148) = 148

rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0

rt_sigsuspend([] <unfinished ...>

--- SIGRTMIN (Unknown signal 32) @ 0 (0) ---

<... rt_sigsuspend resumed> ) = -1 EINTR (Interrupted system call)

sigreturn() = ? (mask now [RTMIN])

waitpid(6050, NULL, __WCLONE) = 6050

munmap(0x40093000, 4096) = 0

exit_group(3) = ?

 

Regards.

Share this post


Link to post
Share on other sites

0: Check your error_log.txt...

1st: Do a clean compile.

2nd: Get rules.xml

3rd: Get the textures

4th: Run it in gdb

 

I don't think it's segfaulting, it probably just exits as it didn't find the rules... There's no segfault in that strace anyway...

Share this post


Link to post
Share on other sites
0: Check your error_log.txt...

1st: Do a clean compile.

2nd: Get rules.xml

3rd: Get the textures

4th: Run it in gdb

 

I don't think it's segfaulting, it probably just exits as it didn't find the rules... There's no segfault in that strace anyway...

Ad 0. In Error log it says browser.lst now found, what the heck is browser.lst and where I am supposed

to find it?

Ad 1. I did a clean compile.

Ad 2. From where?

Ad 3. Which ones?

Ad 4. GDB segfaults on my system hehe.

 

It first time segfaulted, then only crashed with interrupted system call...

 

Regards.

Share this post


Link to post
Share on other sites
I added a small fix about 2 hours ago, that should work... Was related to inaccurate checking of whether the current actor became a null-pointer after getting a server message... I am 100% sure that was the bug you ran into.

How do you inaccurate check for null pointers?

if((ptr+1)/3>0)

Share this post


Link to post
Share on other sites

Actually it was a pointer that pointed to free'd memory. The normal actor* in the actors_list was free()'d and set to 0x0, but the pointer used in display_actors() I was checking wasn't.

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

  • Recently Browsing   0 members

    No registered users viewing this page.

×