Another seg fault in new client

[Puntif]

I refreshed my copy of CVS source this afternoon and recompiled. Runing under Linux I just got a different seg fault when trying to click on the Morcraven signpost to go to Portland:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 21712)]
0x0806eaf8 in click_game_handler (win=0xc413178, mx=414, my=279, 
   flags=2240120197) at gamewin.c:251
251                     str[1] = item_list[item_dragged].pos;
(gdb) bt
#0  0x0806eaf8 in click_game_handler (win=0xc413178, mx=414, my=279, 
   flags=2240120197) at gamewin.c:251
#1  0x08068de8 in click_in_window (win_id=0, x=414, y=279, flags=67108864)
   at elwindows.c:1210
#2  0x08066f10 in click_in_windows (mx=414, my=279, flags=67108864)
   at elwindows.c:168
#3  0x0806bae8 in HandleEvent (event=0xbffff0a0) at events.c:201
#4  0x0807fee4 in start_rendering () at main.c:99
#5  0x08080100 in main (argc=-1499027805, argv=0xa6a6a6a3) at main.c:222
#6  0x40473bb4 in __libc_start_main () from /lib/libc.so.6

- this may be a stack trashing similar to the other one I reported - look at argc/argv.

[trollson]

Yep, same problem -- 'argv' is the hex value of 'argc' again. Furthermore, the point at which the segv occurs appears to be immediately after a 'return' from the function, at which point its trying to unwind the stack. Really suggests that the stack is being screwed up.

 

Puntif, what is your system arch/distro? Have you tried the linux binary? If your the only one seeing this it may be a problem outside ELC.

[Puntif]

I'm running EL on a dual Xeon system using Slackware 9.0 (I'm overdue for an upgrade)

 

I can't use the linux binary due to a problem with the libraries in that distribution - I get some kind of message about can't find the correct version of libpthreads.

 

Since I have turned off the global filters neither problem has reoccurred so I think that might have been the cause of both problems.

[trollson]

Since I have turned off the global filters neither problem has reoccurred so I think that might have been the cause of both problems.

 

So that narrows down the problem then. That will be the 'use_global_filters' option, which triggers a call to 'load_filters_list()' in 'filters.c' (looking at latest cvs).

 

This assumes that the 'global_filters.txt' file:

1. the file is unlocalised ascii (opened as binary and assumed ascii).
   
2. has a new line after each entry (otherwise the last entry will be missed).
   
3. each line is less than 64 bytes long.
   

The last point may be an issue, since each line is copied into a 64 character buffer ('name'), without any overflow guard.

 

There is also a bug in that 'load_filters_list()' assumes that a return of '-1' from 'add_to_filter_list()' means list full, whereas this means that the name is already in the list -- list full is indicated by '-2'. I don't think that this is your problem though, as it would just stop processing after the first duplicate entry.

 

Check what your 'global_filters.txt' file contains; any lines longer than 64 bytes? Non-ascii character encoding?

[Learner]

So that narrows down the problem then.  That will be the 'use_global_filters' option, which triggers a call to 'load_filters_list()' in 'filters.c' (looking at latest cvs).

 

This assumes that the 'global_filters.txt' file:

1. 
    
    
   
2. the file is unlocalised ascii (opened as binary and assumed ascii).
    
   
3. has a new line after each entry (otherwise the last entry will be missed).
    
   
4. each line is less than 64 bytes long.
    
   

The last point may be an issue, since each line is copied into a 64 character buffer ('name'), without any overflow guard.

 

There is also a bug in that 'load_filters_list()' assumes that a return of '-1' from 'add_to_filter_list()' means list full, whereas this means that the name is already in the list -- list full is indicated by '-2'.  I don't think that this is your problem though, as it would just stop processing after the first duplicate entry.

 

Check what your 'global_filters.txt' file contains; any lines longer than 64 bytes?  Non-ascii character encoding?

198164[/snapback]

As posted and #bc'd there is a bug in global filters that can crash you when using it. The problem is incorrect handling of filtering where the new phrase is longer then the original. It can overwrite data coming from the server.