Re: xemacs crashes on startup

On Fri, Jan 2, 2015 at 3:37 PM, Ralf Soergel <Ralf.Soergel(a)t-online.de&gt; wrote: I ran under gdb to see if I could find anything more about this. A little work with a watchpoint shows that the funny value gets stashed into threeD.top_shadow_GC one byte at a time during widget initialization, in particular while setting resources. (What I mean by that is that the nonzero high byte and low byte are set separately, apparently by two different resources.) Here is a backtrace on my machine of the moment when the first nonzero byte is written there (cutting it off at xaw_create_progress, as nothing above that is of interest): #0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:168 #1 0x000000312bc32acc in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=<optimized out>) at /usr/include/bits/string3.h:51 #2 GetResources (widget=0x1245248, widget＠entry=0x1245120, base=0x7fffffff5d1c "\024", base＠entry=0x1245120 " Q$\001", names=0x4, names＠entry=0x7fffffff75a0, classes=0x8, classes＠entry=0x7fffffff7670, table=0x15d, num_resources=333, quark_args=0x1d, args=0x312845d3f0 <resources+240>, num_args=0, typed_args=0x0, pNumTypedArgs=0x7fffffff7d90, tm_hack=4 '\004') at Resources.c:841 #3 0x000000312bc3368c in _XtGetResources (w=w＠entry=0x1245120, args=args＠entry=0x7fffffff7ea0, num_args=num_args＠entry=11, typed_args=typed_args＠entry=0x0, num_typed_args=num_typed_args＠entry=0x7fffffff7d90) at Resources.c:976 #4 0x000000312bc1c6f5 in xtCreate (name=<optimized out>, class=0x0, widget_class=0xb04480 <gaugeClassRec>, parent=0x12415a0, default_screen=0x1241df0, args=0x7fffffff7ea0, num_args=11, typed_args=0x0, num_typed_args=0, parent_constraint_class=0x0, post_proc=0x312bc1be20 <widgetPostProc>) at Create.c:391 #5 0x000000312bc1cbc8 in _XtCreateWidget (name=0x1155bd0 "Progress", widget_class=0xb04480 <gaugeClassRec>, parent=0x12415a0, args=0x7fffffff7ea0, num_args=11, typed_args=0x0, num_typed_args=20) at Create.c:570 #6 0x000000312bc1cead in XtCreateWidget (name=0x1155bd0 "Progress", widget_class=0xb04480 <gaugeClassRec>, parent=0x12415a0, args=args＠entry=0x7fffffff7ea0, num_args=11) at Create.c:589 #7 0x000000000084dae9 in xaw_create_progress (instance=0x1200620) at /home/jamesjer/Projects/xemacs/xemacs-21.5/lwlib/lwlib-Xaw.c:869 The comment at the top of the corrupting code block says: /* go to the resource manager for those resources not found yet */ /* if it's not in the resource database use the default value */ This is the resource that we were processing when we overwrote widget->threeD.top_shadow_GC (with the value 0x14): xrm_name = 1180 / 0x49c xrm_class = 1181 / 0x49d xrm_type = 349 / 0x15d xrm_size = 4 xrm_offset = -297 xrm_default_type = 333 / 0x14d xrm_default_addr = 0x14 It took some hunting around to find this, but I finally managed to figure out that this is index 11 in resources in lwlib/xlwtabs.c: res (XtNtopShadowContrast, XtCTopShadowContrast, XtRInt, int, top_shadow_contrast, XtRImmediate, 20), which gdb shows as: (gdb) print 'xlwtabs.c'::resources[11] $51 = {resource_name = 0x49c <error: Cannot access memory at address 0x49c>, resource_class = 0x49d <error: Cannot access memory at address 0x49d>, resource_type = 0x15d <error: Cannot access memory at address 0x15d>, resource_size = 4, resource_offset = 4294966987, default_type = 0x14d <error: Cannot access memory at address 0x14d>, default_addr = 0x14} The other funny byte is caused by the very next resource, namely: res (XtNbottomShadowContrast, XtCBottomShadowContrast, XtRInt, int, bot_shadow_contrast, XtRImmediate, 40), Now if somebody can figure out why xlwtabs resources are being applied to an xlwgauge widget, we might be able to fix this. -- Jerry James http://www.jamezone.org/ _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta