problems with svn xffm (including stacktrace)

[Mr Machine]

Edscott Wilson Garcia wrote:
> 
> 
> On Sun, 12 Feb 2006, Mr Machine wrote:
> 
>> i'm a bit confused, cos i haven't had xffm-deskview running when these
>> crashes occurred ( ... i've been checking out xfdesktop's new iconified
>> desktop). did you mean i should do:
>>
>> "gdb xffm-iconview core.26519"?
>>
> 
> I see, my mistake. I thought you were dragging to the deskview (which is 
> the folder ~/Destop).
> 
>> in any case, i did both (on a different core file, though ... other one
>> went missing), but i can't see much difference between them:
>>
>> (btw - the crash only happens when drag/copying *the second consecutive*
>> file from one xffm-iconview window to another):
>>
> 
> Is this with any two files and iconview windows? Or just certain iconview 
> windows or files in particular? Maybe a lot of files in the directories 
> or a drop by a priviledged user into a system directory (like the 
> applicacion browser window)?
> 

it appears to be any two iconview windows as well as any two files.
dragging *.desktop files from the application browser to my Desktop
folder always crashes on the second file i copy (actually, it seems this
is the case dragging from any system folder).

if i have two home folders open in two seperate iconview windows and
drag/copy from one to the other, i can usually manage to copy 5 - 8
files before it crashes.

in case it's relevant - my home folders that i was copying to and from
don't have nearly as many files or folders in them than the system ones
i was copying from. the backtraces i've been getting from these crashes
are all the same, too.



> My inability to reproduce the problem makes me suspect a race condition. 
> This would be logical since the update frequency was recently modified.
> 

yeah, i noticed it seems to be getting quicker and quicker ... it's good
to see that modifcation of a folder in iconview now updates the window
properly :)


> This is what I do with the traceback:
>>> #5  0xb7ecbb3a in on_motion (widget=0x80e4c70, event=0x8085cd0, 
> data=0x807bdc0)
>>>     at gridview-callbacks.i:318
> 
> tells me to go to  gridview-callbacks.i:318 where ---within the 
> on_motion function--- there should be another function call.
> 
>  	graphics_saturation_event(icon_view_p,population_p,event->x, 
> event->y);
> 
> Then the traceback specifies:
> 
>>> #4  0xb7ecb931 in graphics_saturation_event (icon_view_p=0x807bdc0,
>>>     population_p=0x863b790, x=332, y=3983) at gridview-callbacks.i:367
> 
> Which coincides with:
> 
>  	    icon_view_p->drag_event.context = gtk_drag_begin 
> (icon_view_p->paper,
>  			   target_list,
>  			   GDK_ACTION_MOVE | GDK_ACTION_COPY | 
> GDK_ACTION_LINK,
>  			    icon_view_p->drag_button,
>  			    (GdkEvent *)(&(icon_view_p->drag_event)));
> 
>>From this point on the program dives into gtk code, so its safe to assume 
> the problem is not further down the line. Something in the above must be 
> pointing to a non valid memory. Since the gtk traceback specifies
> 
>>> #2  0x46753b1c in gtk_drag_set_default_icon ()
> 
> And xffm-iconview sets the drag-icon to match the icon of the object being 
> dragged, the we can pinpoint the problem being that xffm-iconview is 
> destroying the object before gtk can use it. 


hey, thanx for breaking it down like that for me! i've been slowly
getting keen to start learning how to code, and explanations like this
are a great way to ease into it ;)


If with any further
> information I am still unable to reproduce, then I must do 
> some detective work from the point where the drag icon is 
> set until I find the possible race condition.

if the sparse extra info i've given at the top don't help, just let me
know any other tests or info you need and i'll try to help out :)

shayne