[Please note the address list. Since we couldn't clearly assign the bug
to "anything" I post to grace-dev@ as well as lesstif@]
On Mon, 15 May 2000 19:50:49 +0100, C Hennessy wrote:
>Hi Rob,
>
>The last email you sent with the stack trace does not help too much
>as I think that it dies not really show us where the problem is
>occuring.
>So since I have no idea how to use grace, could you please send me a
>data set which is causing you the problem, and a set of [detailed :-]
>instructions on how to recreate the crash.
>
>Thanks,
>CP
>
Well, I'm user of both packages and together wit Rob I tried to
look at it. Unfortunately it doesn't happen for me with the same
versions of grace and lesstif. Main difference is the OS which are
different linux distributions on i86, perhaps also further
setup details.
I omit the details on how to reproduce it (for the experts:
just get some text written in the results window and clear it),
but to sum up yet, we need help and new ideas where to look any further ...
Here are some details:
Some software info (being "xmgrace -version") at the beginning.
We did our best trying to ensure all headers&libs in question
do match, at least I didn't have ideas what else could be wrong.
Grace-5.1.1 (20000507)
GUI toolkit: @(#)GNU/LessTif Version 1.2 Release 0.90.9
Xbae version: 4008
T1lib: 1.0.1-grace
FFT: built-in
NetCDF support: off
Built: Sun May 14 23:56:39 2000 on Linux 2.2.15-2.5.0 i686
Compiler flags: gcc -g -O0 -I.. -I. -I../T1lib/t1lib -g -O0
-I/usr/local/lesstif/include -I/usr/X11R6/include
-L/usr/local/lesstif/lib -L/usr/X11R6/lib -lXbae -lXm -lXpm -lXp -lXmu
-lXt -lXext -lX11 -lSM -lICE ../cephes/libcephes.a ../T1lib/libt1.a
-ltiff -ljpeg -lpng -lz -lm -ldl
The "clear results window" action is linked to a callback (clear_results())
which is simply:
XmTextSetString(monText, "");
We once tried
XmTextSetString(monText, " ")
but that does not help. Crash still occurs.
"Usually" stack traces for the crash (given with LessTif/grace as
debug versions and with "run -sync") are like this:
Program received signal SIGSEGV, Segmentation fault.
0x4025b688 in HandleActions () from /usr/X11R6/lib/libXt.so.6
(gdb) bt
#0 0x4025b688 in HandleActions () from /usr/X11R6/lib/libXt.so.6
#1 0x4025bbd6 in HandleSimpleState () from /usr/X11R6/lib/libXt.so.6
#2 0x4025c111 in _XtTranslateEvent () from /usr/X11R6/lib/libXt.so.6
#3 0x402374e7 in XtDispatchEventToWidget () from
/usr/X11R6/lib/libXt.so.6
#4 0x40237cf5 in DispatchEvent () from /usr/X11R6/lib/libXt.so.6
#5 0x40237fb6 in _XtDefaultDispatcher () from /usr/X11R6/lib/libXt.so.6
#6 0x40238363 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6
#7 0x40238859 in XtAppMainLoop () from /usr/X11R6/lib/libXt.so.6
#8 0x80f1cc4 in startup_gui () at xmgrace.c:1126
#9 0x804f8a5 in main (argc=1, argv=0xbffffb34) at main.c:758
Ok, going on we put a breakpoint at clear_results(), the callback.
Stack looks ok. Is monText somehow broken?
Breakpoint 1, clear_results (data=0x0) at monwin.c:123
123 XmTextSetString(monText, " ");
(gdb) bt
#0 clear_results (data=0x0) at monwin.c:123
#1 0x80c282f in button_int_cb_proc (w=0x8282388, client_data=0x8282378,
call_data=0xbffff72c) at motifutils.c:884
#2 0x4022b8f6 in XtCallCallbackList () from /usr/X11R6/lib/libXt.so.6
#3 0x401341c0 in Activate (w=0x8282388, event=0xbffff8d0, params=0x0,
num_params=0x819eca8) at PushB.c:1065
#4 0x4025b6f4 in HandleActions () from /usr/X11R6/lib/libXt.so.6
#5 0x4025c06d in HandleComplexState () from /usr/X11R6/lib/libXt.so.6
#6 0x4025c11e in _XtTranslateEvent () from /usr/X11R6/lib/libXt.so.6
#7 0x402374e7 in XtDispatchEventToWidget () from
/usr/X11R6/lib/libXt.so.6
#8 0x4023809d in _XtDefaultDispatcher () from /usr/X11R6/lib/libXt.so.6
#9 0x40238363 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6
#10 0x40238859 in XtAppMainLoop () from /usr/X11R6/lib/libXt.so.6
#11 0x80f1cc4 in startup_gui () at xmgrace.c:1126
#12 0x804f8a5 in main (argc=1, argv=0xbffffb34) at main.c:758
(gdb) p monText
$1 = 0x8280678
(gdb) p *monText
$2 = {core = {self = 0x8280678, widget_class = 0x401e0a00, parent =
0x82804e0,
xrm_name = 245, being_destroyed = 0 '\000', destroy_callbacks =0x827db40,
constraints = 0x0, x = 0, y = 0, width = 578, height = 158,
border_width = 0, managed = 1 '\001', sensitive = 1 '\001',
ancestor_sensitive = 1 '\001', event_table = 0x8280810, tm = {
translations = 0x8229138, proc_table = 0x8282eb8, current_state =0x0,
lastEventTime = 613506900}, accelerators = 0x0, border_pixel = 0,
border_pixmap = 2, popup_list = 0x0, num_popups = 0,
name = 0x8180faf "monText", screen = 0x8187ad8, colormap = 33,
window = 46138402, depth = 16, background_pixel = 53052,
background_pixmap = 2, visible = 1 '\001', mapped_when_managed = 1'\001'}}
Among the next ideas was using libefence. Rob tried and citing his
email:
>Alright, a new bug report with EF_ALLOC_MALLOC_0=1.
>In this configuration, however, the SIGSEGV error does not
>occur. The Results window is cleared, but the Electric Fence
>seems to prevent a SIGSEGV crash. The Results window becomes useless
>after clearing it out. For example performing another Non-linear
>fit, will not show the results in the Results window anymore.
A stack trace from clear_results() and XmTextSetString() was still ok.
I can't personally remember libefence fixing/hiding bugs.
We set EF_ALLOC_MALLOC_0=1 but that necessary anyway to get it
"running", there are many malloc(0) calls. Since this shouldn't
cure the real problem what are remaining differences with libefence?
The execution speed is lowered, but in this case and given we have -sync
this doesn't seem to have any meaning.
Now I'm unfortunately at the end of my knowledge and we're both
open to any helpful feedback.
Thanks & Bye,
------------------------------------------------------------------
Alexander Mai
[EMAIL PROTECTED]
------------------------------------------------------------------
