It appears that I am still getting hit (i have no proof yet of causality
) by a SIGSEGV in the memcpy function of:
_XmReadDragBuffer(&bmgr, False, (char *)&nents,
sizeof(CARD16));
I was tired last nite, so i turned off this machine.
This morning i am unable to replicate faithfully the SIGSEGV of last
night :-{
BUT, in the meantime i reviewed "the code" in DragBS.c . Can someone
tell what happens if "&bafter" actually has a number in it ? It does not
appear that you go back to fetch the rest of the data if the data is >
100k.
& does "&nitems" represent the total number of items available, and not
the number of items returned ?
ALSO this pool grows & grows. no one wants to do an equivalent free() on
this pool of DRAG_TARGETS! I am not sure who is at fault here.
/gat
read_targets_table(Display *display, XmDndTargetsTable tbl)
{
...............cut.............
ta = XmInternAtom(display, _XA_MOTIF_DRAG_TARGETS, False);
win = get_drag_window(display);
begin_protection(display, win);
if (XGetWindowProperty(display, /* Display * */
win, /* Window */
ta, /* Atom Property
*/
0L, /* long offset
*/
100000L, /* long length
*/
False, /* Bool delete
*/
ta, /* Atom req_type
*/
&atype, /* Atom act type return
*/
&aformat, /* Atom act format ret
*/
&nitems, /* uLong nitems ret
*/
&bafter, /* uLong bytes after ret
*/
(unsigned char **)&targets /* uchar** prop
ret */
) == Success &&
nitems >= 8)
{
got_it = True;
}
