From time to time, my application crash. Valgrind reports this _all the time_ (which I presume can cause a crash depending on various external factors):
==19431== Invalid free() / delete / delete[]
==19431== at 0x402293C: free (vg_replace_malloc.c:323)
==19431== by 0x42880F0: XtFree (in /usr/X11R6/lib/libXt.so.6.0)
==19431== by 0x416726D: _XmCacheDelete (Cache.c:81)
==19431== by 0x40C6048: _XmReCacheLabG_r (LabelG.c:3659)
==19431== by 0x418AA55: _XmRCDoMarginAdjustment (RCLayout.c:2271)
==19431== by 0x40F3CFB: ChangeManaged (RowColumn.c:1422)
==19431== by 0x40F4147: ConstraintSetValues (RowColumn.c:3122)
==19431== by 0x4171A5A: CSetValuesLeafWrapper (BaseClass.c:2358)
==19431== by 0x4171BC8: CSetValuesLeafWrapper6 (BaseClass.c:2485)
==19431== by 0x42AC69D: (within /usr/X11R6/lib/libXt.so.6.0)
==19431== by 0x42ACE29: XtSetValues (in /usr/X11R6/lib/libXt.so.6.0)
==19431== by 0x42BF531: XtVaSetValues (in /usr/X11R6/lib/libXt.so.6.0)
==19431== by 0x814FA3A: utilities::change_places_for_widgets() (mmi_utilities.cc:801)
==19431== by 0x8050D8C: applicationSpecifics::createInterfaces() (applicationSpecifics.cc:564)
==19431== by 0x8153B98: edhDispatcher::create(_XtAppStruct*, _XDisplay*) (edhDispatcher.cc:831)
==19431== by 0x8051445: main (mmiMain.cc:179)
==19431== Address 0x4279f38 is 24 bytes inside data symbol "extarray"
This is on SuSE Linux 10.1 with openmotif 2.2.4.
Debugging this further, I see that this might be related to the call to _XmCacheDelete having the following parameters:
(gdb) print *ptr
$5 = {next = 0x0, prev = 0x85af858, ref_count = 1818583809}
All calls preceding and future calls have apparently sane values (when it fails it starts with ref_count as 227 - seems like a rather high value, but I don't understand the inner workings here).
It seems to me, since next = 0x0, that ref_count should in this case have been 1.
Does anyone have a lead on how to proceede with this?
After some more digging I
After some more digging I found that the widget used in the call to:
void
_XmReCacheLabG_r(XmLabelGCacheObjPart *local_cache, XmLabelGadget w)
from:
#0 _XmCacheDelete (data=0x4026ef44) at Cache.c:77
#1 0x400bb049 in _XmReCacheLabG_r (local_cache=0xbfc71de8, w=0x85afce8) at LabelG.c:3659
#2 0x4017fa56 in _XmRCDoMarginAdjustment (m=0x85aee58) at RCLayout.c:2271
#3 0x400e8cfc in ChangeManaged (wid=0x85aee58) at RowColumn.c:1422
#4 0x400e9148 in ConstraintSetValues (old=0xbfc72350, req=0xbfc72030, new_w=0x85afce8, args=0x85ba548, num_args=0xbfc71fd8) at RowColumn.c:3122
#5 0x40166a5b in CSetValuesLeafWrapper (current=0xbfc72350, req=0xbfc72030, new_w=0x85afce8, args=0x85ba548, num_args=0xbfc71fd8, depth=6) at BaseClass.c:2358
#6 0x40166bc9 in CSetValuesLeafWrapper6 (current=0xbfc72350, req=0xbfc72030, new_w=0x85afce8, args=0x85ba548, num_args=0xbfc71fd8) at BaseClass.c:2485
#7 0x402a169e in XtSetSensitive () from /usr/X11R6/lib/libXt.so.6
#8 0x402a1e2a in XtSetValues () from /usr/X11R6/lib/libXt.so.6
#9 0x402b4532 in XtVaSetValues () from /usr/X11R6/lib/libXt.so.6
#10 0x0814fa3b in utilities::change_places_for_widgets (this=0x8206260) at /src/libmmi/mmi_utilities.cc:801
#11 0x08050d8d in applicationSpecifics::createInterfaces () at /src/libmmi/applicationSpecifics.cc:564
#12 0x08153b99 in edhDispatcher::create (this=0x82063e0, UxAppContext=0x82240e0, UxDisplay=0x822bf80) at /src/librlib/edhDispatcher.cc:831
#13 0x08051446 in main (argc=1, argv=0xbfc72b24) at /src/libmmi/mmiMain.cc:179
...has an illegal value of the cache reference when the above scenario happens:
(gdb) print w->label.cache
$42 = (XmLabelGCacheObjPart *) 0x4026ef44
...which puts it smack in the middle of libXm:
hci/bin> cat /proc/23182/maps
08048000-081f2000 r-xp 00000000 00:14 6712273 /src/hci/bin/mmi_intgr
081f2000-08201000 rwxp 001a9000 00:14 6712273 /src/hci/bin/mmi_intgr
08201000-085c2000 rwxp 08201000 00:00 0 [heap]
:
:
40035000-40257000 r-xp 00000000 08:02 14467076 /usr/X11R6/lib/libXm.so.3.0.3
40257000-4026f000 rwxp 00222000 08:02 14467076 /usr/X11R6/lib/libXm.so.3.0.3
:
:
To me this seems to indicate that there is an error in the creation (or cache update ?) of either the parent (which is a RowColumn) or one/the last (?) of it's siblings. However, I'm at a loss on how to procede...
is it the same problem wid
is it the same problem wid Xtsetvalues or just Xtvasetvalues
if its not use Xtsetvalues, or hard code them during creation by xtvacreate
uditchandna wrote: Is it
uditchandna wrote:
Is it the same problem wid XtSetValues or just XtVaSetValues
Actually, the problem dissappears when using XtSetValues - strangely enough as XtVaSetValues calls XtSetValues... Does that mean that the bug is elsewhere (in Xt)?
It would be helpful if you
It would be helpful if you showed some of your actual code.
The problem is more likely to be a memory mismanagement in some other part of the code.
fredk wrote: It would be
fredk wrote:
It would be helpful if you showed some of your actual code.
Sorry about that. One tend to delve deep into the technicalities and forget that other people might not have the same understanding. :) Here goes:
Widget FirstWidget;
Widget SecondWidget;
Widget ParentWidget;
Position firstPos, secondPos;
:
if (XmIsRowColumn(ParentWidget)) {
// Get packing mode for the row column
XtVaGetValues(ParentWidget,
XmNpacking, &packing,
XtNheight, &height,
XmNspacing, &spacing,
NULL);
// Get widgets position indexes
XtVaGetValues(FirstWidget, XmNpositionIndex, &firstPos, NULL);
XtVaGetValues(SecondWidget, XmNpositionIndex, &secondPos, NULL);
// Switch position indexes
XtVaSetValues(FirstWidget, XmNpositionIndex, secondPos, NULL); // The crash/corruption happens here
XtVaSetValues(SecondWidget, XmNpositionIndex, firstPos, NULL);
// Reset packing mode for the row column
XtVaSetValues(ParentWidget,
XmNpacking, packing,
XtNheight, height,
XmNspacing, spacing,
NULL);
} else {
XtVaGetValues(FirstWidget, XtNx, &firstX,
XtNy, &firstY, NULL);
XtVaGetValues(SecondWidget, XtNx, &SecondX,
XtNy, &SecondY, NULL);
XtVaSetValues(FirstWidget,
XtNx, SecondX,
XtNy, SecondY,
XmNleftAttachment, XmATTACH_NONE,
XmNrightAttachment, XmATTACH_NONE,
NULL);
XtVaSetValues(SecondWidget,
XtNx, firstX,
XtNy, firstY,
XmNleftAttachment, XmATTACH_NONE,
XmNrightAttachment, XmATTACH_NONE,
NULL);
}
Quote:
The problem is more likely to be a memory mismanagement in some other part of the code.
I seriously doubt that. Firstly, the code is very simple; what happens before the code above is that it retrieves pairs of widgets which is checked for existance and the operated on according to above. Secondly, when I changed to:
Arg firstArg;
Arg secondArg;
XtSetArg(firstArg, XmNpositionIndex, &firstPos);
XtSetArg(secondArg, XmNpositionIndex, &secondPos);
:
// Get widgets position indexes
XtGetValues(FirstWidget, &firstArg, 1);
XtGetValues(SecondWidget, &secondArg, 1);
// Switch position indexes
XtSetValues(FirstWidget, &secondArg, 1);
XtSetValues(SecondWidget, &firstArg, 1);
...the problem went away. Thirldy, we have no troubles with exact the same code on SPARC Solaris.
If indeed you wrote: // Get
If indeed you wrote:
// Get widgets position indexes
XtGetValues(FirstWidget, &firstArg, 1);
XtGetValues(SecondWidget, &secondArg, 1);
// Switch position indexes
XtSetValues(FirstWidget, &secondArg, 1);
XtSetValues(SecondWidget, &firstArg, 1);
Then it cannot possibly work correctly. There should be
no '&' characters in the SetValues calls.
If there is a problem using the variadic calls (XtVa...),
and it appears to disappear when using the non-variadic
calls, I still contend that there is likely to have been
some kind of mamory mismanagement. The variadic calls
will invoke malloc() and free() internally, which may
fail if there has been a prior memory problem.
Have you tried using Widgets instead of Gadgets for the labels?
--
Fred K
fredk wrote: If indeed you
fredk wrote:
If indeed you wrote:
// Get widgets position indexes
XtGetValues(FirstWidget, &firstArg, 1);
XtGetValues(SecondWidget, &secondArg, 1);
// Switch position indexes
XtSetValues(FirstWidget, &secondArg, 1);
XtSetValues(SecondWidget, &firstArg, 1);
Then it cannot possibly work correctly. There should be
no '&' characters in the SetValues calls.
What you didn't see was:
Arg firstArg;
Arg secondArg;
...not an array of arguments. And it compiles and works as intended.
Quote:
If there is a problem using the variadic calls (XtVa...),
and it appears to disappear when using the non-variadic
calls, I still contend that there is likely to have been
some kind of mamory mismanagement. The variadic calls
will invoke malloc() and free() internally, which may
fail if there has been a prior memory problem.
The only thing happening before this function is the creation of tons of widgets. Nothing much else related to the management of the widgets.
Purify on Solaris does not report any memory issues and it has never crashed on Solaris either. Valgrind reports on only ONE of the calls and if I remove that particular set of widgets, there are no reports.
Quote:
Have you tried using Widgets instead of Gadgets for the labels?
--
Fred K
No, but you got me thinking and I located the source of the problem. As it happens, two of the sibling label gadgets (within the same RC) had XmNmarginLeft set in the call to XtVaCreateManagedWidget(...). Removing those cure the problem.
Something in the label gadget code which creates an illegal cache entry?