Jump to content
Eternal Lands Official Forums
heu

Client crash while changing maps...

Recommended Posts

I found a crash which I am able to reproduce.

 

When you are changing maps (entenring a storage or whatever), if you grab a fruit (with the drag pointer I mean) quickly while the new map is loading, the client crashes. (Segmentation fault).

 

The crash was reproduced in my Linux machine and Anamir could also reproduce it in a Windows machine.

 

The weird thing is that it doesn't seem to work with all items, at first it happened with fruits, then I could reproduce it with HE's but I couldn't with a pickaxe.

 

Not sure if this is clear... you can always PM me ingame if you need more details.

Share this post


Link to post
Share on other sites

i am getting a simular crash. when leaving a building it completely locks up the client. have to close and restart. only happens changing maps, and has happened numerous times.

 

i am running vista on an hp laptop, dual amd, 2 gig ram, 256 video (geforce)

 

all drivers are up to date and current, never had any problems before.

Share this post


Link to post
Share on other sites

i am getting a simular crash. when leaving a building it completely locks up the client. have to close and restart. only happens changing maps, and has happened numerous times.

 

i am running vista on an hp laptop, dual amd, 2 gig ram, 256 video (geforce)

 

all drivers are up to date and current, never had any problems before.

 

I don't think they are the same bugs... I have no problem at all with changing maps only. The crash happens only when you grab something from inv while changing maps.

 

Edit: btw, as there's a fix for that "random crashing bug" for windows, assuming that the fix is on the cvs now, it doesn't fix the bug I found as I just tested it.

Edited by heu

Share this post


Link to post
Share on other sites

not only when u change maps. it also happens when u use a secret or a teleporter(havnt tried the teleporter, but I guess they work as secrets) into the same map.

 

(I got the linux ver)

Edited by mortsllehm

Share this post


Link to post
Share on other sites

Yep I got that too, I noticed it as when I eat fruit while changing or just before changing maps so it happens if you "use" and well as move.

 

EDIT : Windows XP

Edited by FatboyJaxx

Share this post


Link to post
Share on other sites

Stack trace from TommyKnocker, intel mac

 

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000004

Thread 0 Crashed:
0 <<00000000>> 0x1db95a68 0 + 498686568
1 GLEngine 0x18cfe199 gleDrawArraysOrElements_Core + 157
2 GLEngine 0x18d82eef gleDrawArraysOrElements_VBO_Exec + 853
3 libGL.dylib 0x92b1a575 glDrawArrays + 97
4 com.yourcompany.el_osx 0x000e6296 draw_terrain_quad_tiles + 375
5 com.yourcompany.el_osx 0x000e67b4 draw_tile_map + 513
6 com.yourcompany.el_osx 0x00068cdd display_game_handler + 483
7 com.yourcompany.el_osx 0x00058e9e draw_window + 290
8 com.yourcompany.el_osx 0x0005905b display_windows + 142
9 com.yourcompany.el_osx 0x0004817a draw_scene + 149
10 com.yourcompany.el_osx 0x000919b7 start_rendering + 244
11 com.yourcompany.el_osx 0x00091d1c SDL_main + 55

Share this post


Link to post
Share on other sites

Hmm, I wonder if this could cause the problem on windows too?

Maybe we should release a test client without the tile map to see if people still have crashes or not..

Share this post


Link to post
Share on other sites

Found a spot that crashes my client.

 

tile_map.c

void draw_terrain_quad_tiles(unsigned int start, unsigned int stop)

Line 157

glDrawArrays(GL_QUADS, idx * 4, size * 4);

 

Program received signal SIGSEGV, Segmentation fault.

[switching to Thread 47524477636288 (LWP 15898)]

0x00000000400019ff in ?? ()

(gdb) bt

#0 0x00000000400019ff in ?? ()

#1 0x0000000040002000 in ?? ()

#2 0x00002aaaab4802d4 in ?? ()

#3 0x0000000000000004 in ?? ()

#4 0x0000000040002000 in ?? ()

#5 0x00002b392719842c in ?? () from //usr/lib64/opengl/nvidia/lib/libGLcore.so.1

#6 0x00002b3926ed7018 in ?? () from //usr/lib64/opengl/nvidia/lib/libGLcore.so.1

#7 0x00000000004b475b in draw_terrain_quad_tiles (start=13, stop=14) at tile_map.c:153

#8 0x00000000004b492d in draw_tile_map () at tile_map.c:278

#9 0x0000000000456e3f in display_game_handler (win=0x46f38a0) at gamewin.c:978

#10 0x000000000044930a in draw_window (win=0x46f38a0) at elwindows.c:1137

#11 0x00000000004499bc in display_window (win_id=0) at elwindows.c:1307

#12 0x0000000000446a4e in display_windows (level=1) at elwindows.c:75

#13 0x000000000043f93e in draw_scene () at draw_scene.c:116

#14 0x00000000004778aa in start_rendering () at main.c:168

#15 0x0000000000477c5f in main (argc=1, argv=0x7fff85e3dbd8) at main.c:302

 

 

Linux 2.6.19-gentoo-r5 #3 SMP x86_64 AMD Athlon 64 X2 Dual Core Processor 4400+ AuthenticAMD GNU/Linux

 

x11-drivers/nvidia-drivers 1.0.8776

 

01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600 GT] (rev a1) (prog-if 00 [VGA controller])

Subsystem: ASUSTeK Computer Inc. Unknown device 81f7

Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-

Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

Latency: 0

Interrupt: pin A routed to IRQ 18

Region 0: Memory at d0000000 (32-bit, non-prefetchable)

Region 1: Memory at c0000000 (64-bit, prefetchable)

Region 3: Memory at d1000000 (64-bit, non-prefetchable)

Region 5: I/O ports at a000

[virtual] Expansion ROM at d2000000 [disabled]

Capabilities: [60] Power Management version 2

Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)

Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Capabilities: [68] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-

Address: 0000000000000000 Data: 0000

Capabilities: [78] Express Endpoint IRQ 0

Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-

Device: Latency L0s <1us, L1 <4us

Device: AtnBtn- AtnInd- PwrInd-

Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-

Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+

Device: MaxPayload 128 bytes, MaxReadReq 512 bytes

Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0

Link: Latency L0s <1us, L1 <4us

Link: ASPM Disabled RCB 128 bytes CommClk- ExtSynch-

Link: Speed 2.5Gb/s, Width x16

Capabilities: [100] Virtual Channel

Capabilities: [128] Power Budgeting

Edited by codercr

Share this post


Link to post
Share on other sites

My Issue was resolved with an Nvidia upgrade.

 

My trace and data showed that the issue was in the nvidia opengl driver I was using.

 

I am now using the NVIDIA Driver version 100.14.09

 

Found a spot that crashes my client.

 

tile_map.c

void draw_terrain_quad_tiles(unsigned int start, unsigned int stop)

Line 157

glDrawArrays(GL_QUADS, idx * 4, size * 4);

 

Program received signal SIGSEGV, Segmentation fault.

[switching to Thread 47524477636288 (LWP 15898)]

0x00000000400019ff in ?? ()

(gdb) bt

#0 0x00000000400019ff in ?? ()

#1 0x0000000040002000 in ?? ()

#2 0x00002aaaab4802d4 in ?? ()

#3 0x0000000000000004 in ?? ()

#4 0x0000000040002000 in ?? ()

#5 0x00002b392719842c in ?? () from //usr/lib64/opengl/nvidia/lib/libGLcore.so.1

#6 0x00002b3926ed7018 in ?? () from //usr/lib64/opengl/nvidia/lib/libGLcore.so.1

#7 0x00000000004b475b in draw_terrain_quad_tiles (start=13, stop=14) at tile_map.c:153

#8 0x00000000004b492d in draw_tile_map () at tile_map.c:278

#9 0x0000000000456e3f in display_game_handler (win=0x46f38a0) at gamewin.c:978

#10 0x000000000044930a in draw_window (win=0x46f38a0) at elwindows.c:1137

#11 0x00000000004499bc in display_window (win_id=0) at elwindows.c:1307

#12 0x0000000000446a4e in display_windows (level=1) at elwindows.c:75

#13 0x000000000043f93e in draw_scene () at draw_scene.c:116

#14 0x00000000004778aa in start_rendering () at main.c:168

#15 0x0000000000477c5f in main (argc=1, argv=0x7fff85e3dbd8) at main.c:302

 

 

Linux 2.6.19-gentoo-r5 #3 SMP x86_64 AMD Athlon 64 X2 Dual Core Processor 4400+ AuthenticAMD GNU/Linux

 

x11-drivers/nvidia-drivers 1.0.8776

 

01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600 GT] (rev a1) (prog-if 00 [VGA controller])

Subsystem: ASUSTeK Computer Inc. Unknown device 81f7

Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-

Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

Latency: 0

Interrupt: pin A routed to IRQ 18

Region 0: Memory at d0000000 (32-bit, non-prefetchable)

Region 1: Memory at c0000000 (64-bit, prefetchable)

Region 3: Memory at d1000000 (64-bit, non-prefetchable)

Region 5: I/O ports at a000

[virtual] Expansion ROM at d2000000 [disabled]

Capabilities: [60] Power Management version 2

Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)

Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Capabilities: [68] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-

Address: 0000000000000000 Data: 0000

Capabilities: [78] Express Endpoint IRQ 0

Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-

Device: Latency L0s <1us, L1 <4us

Device: AtnBtn- AtnInd- PwrInd-

Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-

Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+

Device: MaxPayload 128 bytes, MaxReadReq 512 bytes

Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0

Link: Latency L0s <1us, L1 <4us

Link: ASPM Disabled RCB 128 bytes CommClk- ExtSynch-

Link: Speed 2.5Gb/s, Width x16

Capabilities: [100] Virtual Channel

Capabilities: [128] Power Budgeting

Share this post


Link to post
Share on other sites
Guest TuultenJumala

Hi,

 

The problem is that on a map change a kill_all_actor is sent from the server.

which resets the actor_list and sets your_actor to NULL

 

if you take an item from the inv a sound according to that item has to be played.

(item.c line 680) which accesses your_actor which is NULL :) until the actors have been readded

on map change complete

Share this post


Link to post
Share on other sites

Hi,

 

The problem is that on a map change a kill_all_actor is sent from the server.

which resets the actor_list and sets your_actor to NULL

 

if you take an item from the inv a sound according to that item has to be played.

(item.c line 680) which accesses your_actor which is NULL :) until the actors have been readded

on map change complete

You're right. I've now been able to reproduce this just my clicking on an inventory window while changing maps. Takes me a few goes but that's the nature of this type of problem.

 

The even more important thing here is that this crash still happens even if you have sound and music turned off. This is because the code is still run even though no sound will be produced.

 

I think we need to produce a test client that has NEW_SOUND disabled, see is that fixes peoples problems.

 

edit: A liberal sprinkling of "if (your_actor)" around the calls to add_sound_object() appears to be a good start in fixing this....

Edited by bluap

Share this post


Link to post
Share on other sites

A liberal sprinkling of "if (your_actor)" around the calls to add_sound_object() appears to be a good start in fixing this....

Just so folks know, I'm working on a fixing this now....

Share this post


Link to post
Share on other sites

Hi,

 

The problem is that on a map change a kill_all_actor is sent from the server.

which resets the actor_list and sets your_actor to NULL

 

if you take an item from the inv a sound according to that item has to be played.

(item.c line 680) which accesses your_actor which is NULL :( until the actors have been readded

on map change complete

You're right. I've now been able to reproduce this just my clicking on an inventory window while changing maps. Takes me a few goes but that's the nature of this type of problem.

 

The even more important thing here is that this crash still happens even if you have sound and music turned off. This is because the code is still run even though no sound will be produced.

 

I think we need to produce a test client that has NEW_SOUND disabled, see is that fixes peoples problems.

 

edit: A liberal sprinkling of "if (your_actor)" around the calls to add_sound_object() appears to be a good start in fixing this....

 

I just compiled the cvs with NEW_SOUND disabled and it did fix the crash.

You're on the right track. :P

Share this post


Link to post
Share on other sites

Excellent :happy:

Bluap, when you finish fixing this, please post it in the feature freeze thread.

 

TuultenJumala, thanks for the fine detective work :)

Share this post


Link to post
Share on other sites

crashez8.png

 

Desert Pines Coal Cave (south).

When I enter in this cave, I get always a crash except if I am in 366,94 (the place where we are when we exit from the cave) and in 366,93.

 

Graphic Card: Asus N6200, 128MB

Edited by Blodoks

Share this post


Link to post
Share on other sites
edit: A liberal sprinkling of "if (your_actor)" around the calls to add_sound_object() appears to be a good start in fixing this....

Offtopic - not helpful to bug

I would've thought any programmer worth their salt would check for NULLs, just out of good practice.

Share this post


Link to post
Share on other sites
edit: A liberal sprinkling of "if (your_actor)" around the calls to add_sound_object() appears to be a good start in fixing this....

Offtopic - not helpful to bug

I would've thought any programmer worth their salt would check for NULLs, just out of good practice.

Not sure if that's targeted at me or the original author. I get used to C++ where use of NULL is a no-no, zero being used instead and hence you can rely on the if (var) rather than if (var!=NULL). I believe most C compilers are safe with the former now...

Share this post


Link to post
Share on other sites
edit: A liberal sprinkling of "if (your_actor)" around the calls to add_sound_object() appears to be a good start in fixing this....

Offtopic - not helpful to bug

I would've thought any programmer worth their salt would check for NULLs, just out of good practice.

Not sure if that's targeted at me or the original author. I get used to C++ where use of NULL is a no-no, zero being used instead and hence you can rely on the if (var) rather than if (var!=NULL). I believe most C compilers are safe with the former now...

Two reasons to compare to NULL instead of 0 is in case some CPU platform needs to have a special value other then 0 and NULL can be passed without casting in C++. You aren't supposed to assume NULL == 0.

Share this post


Link to post
Share on other sites

Two reasons to compare to NULL instead of 0 is in case some CPU platform needs to have a special value other then 0 and NULL can be passed without casting in C++. You aren't supposed to assume NULL == 0.

This conversion might never end so I will not comment further. :hug:

Share this post


Link to post
Share on other sites

heh.

 

0 is an int. Not a char, not a short, but an int.

 

NULL is usually a macro, defined as ((void*)0). So it is a pointer.

 

In C++, NULL (at least in gcc) is internal to the compiler, and translates as __null.

 

You can see for yourselves with:

 

(echo "#include <stdio.h>"; echo "int main() { return NULL; }" ) > nulltest.c
$ gcc -E nulltest.c | tail -n 1
int main() { return ((void *)0); }

 

and :

$ g++ -E nulltest.c | tail -n 1
int main() { return __null; }

 

 

Comparing a pointer with 0 is not a good practice.

Comparing 0 with a pointer isn't either.

 

I often use (NULL==pointer) instead of (pointer==NULL). This is just because, if you miss an equalsign, it won't even compile. Otherwise it might assume you're really assigning NULL to your pointer.

 

Edit : fix a typo

Álvaro

Edited by alvieboy

Share this post


Link to post
Share on other sites

Offtopic - not helpful to bug

I would've thought any programmer worth their salt would check for NULLs, just out of good practice.

 

I almost never check my pointers, unless if I know that there is a posibility for them to be NULL because of some dynamical stuff.

Share this post


Link to post
Share on other sites

Offtopic - not helpful to bug

I would've thought any programmer worth their salt would check for NULLs, just out of good practice.

 

I almost never check my pointers, unless if I know that there is a posibility for them to be NULL because of some dynamical stuff.

And your_actor is one of those pointers that can easily be NULL at times (between when a map change starts and when actors list is sent & the YOU_ARE packet is received, or a resync is happening).

Share this post


Link to post
Share on other sites

Yes, that is. There are other places in the code where it is tested, to make sure it's valid (such as when determining your map position, etc.)

Share this post


Link to post
Share on other sites

I almost never check my pointers, unless if I know that there is a posibility for them to be NULL because of some dynamical stuff.

Of course, testing where it's relevant. Doing:

char[5] my_str = "hello";
if(my_str != NULL){ // some uber code }

 

would be pointless. I meant in other cases, where it's not as clear (such as a function parameter or return value).

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.

×