you wrote

I don't think the bug is in syslinux itself, but in a function calling a syslinux function with wrong parameters, for example a move(nil,nil,1) or something like that.

I recompiled the library with debug info (thanks for info for a newcomer,Peter) and what I found was that the real problem , line 114

	function TObject.ClassType : TClass;
	 begin
	 ClassType:=TClass(Pointer(Self)^) <--- here
	 end;
	and the information says: Program received signal
	SIGSEGV, segmentaion fault.
	0x807790 in TOBJECT_CLASSTYPE (this=Cannot access
	memory at addres NxN) at objpas.inc:114
	NxN varies from 0x0 to 0x5 depending on the problematic
	keys pressed (Tab=0x0, other values arrow keys).
	Hope this helps correct the problems, as a rookie I
	cannot yet find the problem.

Markku

Another hint:

type 'bt' in gdb to see a backtrace from which placed it's called. Because the call to this tobject method is with the wrong 'this' the bug is in the caller

Peter

I don't think the bug is in syslinux itself, but in a function calling a syslinux function with wrong parameters, for example a move(nil,nil,1) or something like that.

But to be sure compile the linux rtl with debug info:

go to rtl/linux and type:

make clean
make OPT=-g

Peter

I have been investigating the memory loss in the editor and it seems to me that at least some of the gdk function calls are behind it.

I made the timer tic to 50 ms to speed up the memory loss, added exits to TGtkObject.DrawFillRect and found out that after each call to gdk_draw_rectangle there was a loss of system memory (seen in Linux TOP monitor). Is there a bug in the gdk interface?

The memory consumption is notable; after making the timer update the text in the editor for some time X seemed to swell to more than 30 MB which finally froze up Linux completely. This is a sign that the gdk_draw_text call is buggy as well.

Are we possibly having stack problems?

As for the keyboard crashing the demo applications crash whenever an arrow key or Tab is pressed. GDB tells me that the crash occurred in _SYSLINUX.

Markku

you wrote

type 'bt' in gdb to see a backtrace from which placed it's called. Because the call to this tobject method is with the wrong 'this' the bug is in the caller

Okay, now I have done some backtracing in the
LCL made windows. This is what happens when
the LEFT key is pressed. Problems occur with the
following keys (the address(BT line #1) is given as well):

TAB 0x0
UP 0x2
LEFT 0x4
DOWN 0x3
RIGHT 0x5

The apps only crash using these keys, possibly there is "address 0x0" hanging somewhere as well. Do these keys have special handling in GDK? I have not been able to find the explanation yet. The backtrace when RIGHT KEY is pressed is as follows:

#0 0x807bae4 in TOBJECT__CLASSTYPE (this=Cannot access memory at address0x5.) at objpas.inc:114
#1 0x807bc1c in TOBJECT__DISPATCH (MESSAGE=void, this= Cannot access memory at address 0x5.) at objpas.inc:209 #2 0x805570a in gtkfocusCB () at buttons.inc:97
#3 0x81256b0 in gtk_marshal_INT () at syslinux.pp:723 #4 0x80f87b4 in gtk_handlers_run () at syslinux.pp:723 #5 0x80f7e17 in gtk_signal_real_emit () at syslinux.pp:723 #6 0x80f656a in gtk_signal_emit () at syslinux.pp:723 #7 0x809fd88 in gtk_container_focus () at syslinux.pp:723 #8 0x81245b4 in gtk_window_key_press_event () at syslinux.pp:723 #9 0x81255f0 in gtk_marshal_BOOL__POINTER () at syslinux.pp:723 #10 0x80f7e4d in gtk_signal_real_emit () at syslinux.pp:723 #11 0x80f656a in gtk_signal_emit () at syslinux.pp:723 #12 0x811e4d8 in gtk_widget_event () at syslinux.pp:723 #13 0x80d48ba in gtk_propagate_event () at syslinux.pp:723 #14 0x80d3edf in gtk_main_do_event () at syslinux.pp:723 #15 0x400fcb02 in gdk_event_dispatch (source_data=0x0, current_time=0xbffffc1c, user_data=0x0) at gdkevents.c:2098 #16 0x8130ffe in g_main_dispatch () at syslinux.pp:723 #17 0x81314bd in g_main_iterate () at syslinux.pp:723 #18 0x81315cf in g_main_run () at syslinux.pp:723
#19 0x80d3a8b in gtk_main () at syslinux.pp:723
#20 0x8056184 in _GTKINT () at buttons.inc:97
#21 0x805d274 in TAPPLICATION__RUN (
this={<TCOMPONENT> = {<TPERSISTENT> = {<TOBJECT> = {_vptr. = {0x8165d0b,
0x0}}, }, FOWNER = 0x0, FNAME = 0x0, FTAG = 0,
FCOMPONENTS = 0x816f644, FFREENOTIFIES = 0x0, FDESIGNINFO = 0,

FVCLCOMOBJECT = 0x0, FCOMPONENTSTATE = Invalid C/C++ type code 10
in symbol table.
) at application.inc:53
#22 0x807fc12 in program_init () at syslinux.pp:723 #23 0x8050a0f in _haltproc ()

you wrote

navigation keys also be passed. I've just spent half an hour trying to find the funciton/message. I had to us it once but forget which project.

I suspect that the case is something like that. However, the message loop detects one of the arrow keys and the TAB key as a 'keypress' and the runtime library is very upset as the message is probably not what is thinks it should be.

One can crash any of the demo applications as well even though there is no keyboard event function. This is a sign about a problem in the RTL.

Another problem is the GDK calling routine that eats up available memory and finally crashes Linux. I sent a demo app some time ago that should demonstrate
the problem.

The person that isolates/corrects one of these problems will receive a a cigar from me :-)

Markku

I recollect in Delphi (windows) that these keys are navigation keys for navigating BETWEEN controls and by default are not passed to the controls unless you (and here it escapes me) call some function to request that these navigation keys also be passed. I've just spent half an hour trying to find the funciton/message. I had to us it once but forget which project.

I find it strange to think it affects you... but your description of the affected keys seems to match the problem.

I hope this is enought to go on. (Maybe GTK is similar)

Sam