[AD] electricfence testing results

[Martijn Versteegh <m.versteegh@xxxxxxxxxx>]

Hi all,

I didn't have time to get the latest cvs version yet, but I did some tests
on '38 instead.

When run with the electricfence memory debugger I get a segmentation fault
under these conditions:

-running in X, 16 bit colordepth, while the program runs in 24 bit colordepth
-linking with the shared lib (when linking statically the crash disappears)

when run from within gdb I get the following traceback from a program of mine:
--------------
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 11281)]
0x805e148 in sprite_x_loop_draw_sprite () at test.cpp:513
513     {
Current language:  auto; currently c++
(gdb) bt
#0  0x805e148 in sprite_x_loop_draw_sprite () at test.cpp:513
#1  0x85c8002b in ?? ()
#2  0x400c6481 in _xwin_replace_vtable () from /usr/local/lib/liballd-3.9.38.so
#3  0x4008a976 in draw_sprite () from /usr/local/lib/liballd-3.9.38.so
#4  0x4009df94 in gfx_mode_select_ex () from /usr/local/lib/liballd-3.9.38.so
#5  0x4009e9c5 in show_mouse () from /usr/local/lib/liballd-3.9.38.so
#6  0x805217a in init () at test.cpp:254
#7  0x80525c3 in _mangled_main (argc=2, argv=0xbffff57c) at test.cpp:340
#8  0x400bb8b5 in main () from /usr/local/lib/liballd-3.9.38.so
#9  0x40130baf in __libc_start_main () from /lib/libc.so.6
(gdb) 



because the line numbers are screwed up (I never know how to get gdb
to do them right when the crash is in a library, and the sourcefiles
are somewhere else) it is hard to find out what exactly happened,
but it is somewhere in the i386 asm code as far a I can see.



-----------------
The test program (tests/test)gives:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 18313)]
0x8068088 in _linear_draw_sprite24 ()
(gdb) bt
#0  0x8068088 in _linear_draw_sprite24 ()
#1  0x400c131e in _xwin_replace_vtable ()
   from /usr/local/lib/liballeg-3.9.38.so
#2  0x400 in ?? ()
Cannot access memory at address 0x400
(gdb)

---------------------
when I disable asm (configure --disable-asm) I get exactly the same traceback,
so it's not asm related here , or so it seems anyway.

My guess is it is a problem with the X color converters.

I don't have anymore time today, but if necessary I'll try to do some more tests
with other color depths



My experiences with electricfence are quite good, I've never seen it giving
'false alarms'.




--------------------------------------------------------------

another bug:

when I run the test program in 16 bits 800x600 fbcon console, the
first chooser dialog comes up alrightm, but when I continue I get


  Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens <bruce@xxxxxxxxxx>

ElectricFence Aborting: free(400e3c7c): address not from malloc().
Shutting down Allegro due to signal #4


This is probably a bug in the modelist fetching, and is probably already fixed in cvs


---------------------


another problem which has been around for some time:

Whenever I have run an allegro program in fbcon mode and
I switch back to X (some time after the program finished, or while
the program runs, that doesn't matter) the machine hanges. Completely wedged,
not even ctrl-alt-del works (magic sysrq seems not to work anymore in 2.4 kernels).

needs a cold reboot.

I don't understand how this can happen, for you don't need to do anything weird for
the fb console.

Maybe we could add a safe-fbcon mode which just uses whatever
resolution/colordepth/refresh rate  the console is in at the moment, and does not try
to change anything. Using the same color-convertors X uses.


--
Martijn Versteegh