Crash when accepting file transfert of disconnected user

[jim++]

I was away. When I came back I saw a file transfert request. I accepted and then, crash. I see in xml that contact disconnected during that time.

Full xml with gdb backtrace attached.

[dkirov]

Indeed, we don't remove the notification or ft request dialog when the initiator goes offline adn we should do it.

I cannot reproduce the crash and there are other situations in which gajim crash with segfault, which are reproducable, but I think this one is not directly related to the ft accepta action. If you take a look at the staza on line 3, it is invalid xml:

<iq id='ab36a' to='jim@jabber.fr/GaJim' type='set' from='puyo@jabber.fr/Psi'>
    <si id='s5b_ad93b2a004b45941' 
    	profile='http://jabber.org/protocol/si/profile/file-transfer' 
    	xmlns='http://jabber.org/protocol/si'>
    <file name='silent hill (8- them of u.f.o.).mp3' size='2444643'
	xmlns='http://jabber.org/protocol/si/profile/file-transfer'>
    	<range/>
    </file>
    <feature xmlns='http://jabber.org/protocol/feature-neg'>
    	<x type='form' xmlns='jabber:x:data'>
    		<field var='stream-method' type='list-single'>
    			<option>
	    			<value>http://jabber.org/protocol/bytestreams</value>
    			</option>
    		</field>

e.g. it misses </x></feature></iq> Maybe this caused expat to fail later. It is weird that after this message you received other stanzas from him. Can you talk to puyo to report these stanzas to psi. In the meanwhile we will make the fix for removing ft notifications from disconnected users.

[dkirov]

note: it misses </x></feature></si></iq> end tags.

There is a backslash at the end of line 3, which looks out of place. Is it possible that you didn't paste all the output, or trac cut part of the line?

[jim++]

Yes you're right trac cut it because the line is very long. See "Original Format" at bottom of page.

[dkirov]

The crash is caused, because of the modality of FT request dialog, which means that every modal dialog can lead to the same crash. If we want to prevent further gajim crashes we need to turn all modal dialogs to nonmodal. I can think of one dialog that may remain modal and this is error dialog about insufficient disk space. The rest don't need modality, because Gajim may have more than one account and event which concerns one of the accounts shouldn't stop UI iteraction with the others.

Other than that is the notification removal fix.

[asterix]

this pb of modal dialog is indeed a real big pb: when we receive a gc invitation, the window is modal and in code there is a dialog.run(). This means we don't revieve nor send other things until we reply to the invitation ! So I totaly agree to remove all those modal dialogs except disk space one

[nk]

#777 is there a long time (1000 tickets before this) and it for another reason (a UI one).

btw the dialog about not enough hd space does not always get triggered, but it's not but GNOME that should do this notifications anyways.

on the modality and many pending events make Gajim crash I could reproduce but I don't know who to blame, but I do not think rm'ing the concept of modality is the cure. it's like your nail hurts and you cut your full arm.

my static without debuging builts of GTK/PyGTK (maybe Dimitur on Gentoo can debug more says):

Backtrace was generated from '/opt/gnome/libexec/gajim'

(no debugging symbols found)
Using host libthread_db library "/lib/tls/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1212074304 (LWP 4669)]
[New Thread -1264575568 (LWP 4817)]
[New Thread -1260438608 (LWP 4816)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in ?? ()
#0  0xffffe410 in ?? ()
#1  0xbfa91178 in ?? ()
#2  0x00000000 in ?? ()

Thread 3 (Thread -1260438608 (LWP 4816)):
#0  0xffffe410 in ?? ()
No symbol table info available.
#1  0xb4df33c8 in ?? ()
No symbol table info available.
#2  0xffffffff in ?? ()
No symbol table info available.
#3  0x00000009 in ?? ()
No symbol table info available.
#4  0xb7cc66f3 in poll () from /lib/tls/libc.so.6
No symbol table info available.
#5  0xb77b2e1c in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#6  0xb77b3317 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#7  0xb54e9f50 in link_io_thread_fn () from /opt/gnome/lib/libORBit-2.so.0
No symbol table info available.
#8  0xb77cd991 in g_thread_create_proxy () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#9  0xb7e46240 in start_thread () from /lib/tls/libpthread.so.0
No symbol table info available.
#10 0xb7cd003e in clone () from /lib/tls/libc.so.6
No symbol table info available.

Thread 2 (Thread -1264575568 (LWP 4817)):
#0  0xffffe410 in ?? ()
No symbol table info available.
#1  0xb4a01468 in ?? ()
No symbol table info available.
#2  0x00000003 in ?? ()
No symbol table info available.
#3  0x00000000 in ?? ()
No symbol table info available.

Thread 1 (Thread -1212074304 (LWP 4669)):
#0  0xffffe410 in ?? ()
No symbol table info available.
#1  0xbfa91178 in ?? ()
No symbol table info available.
#2  0x00000000 in ?? ()
No symbol table info available.
#0  0xffffe410 in ?? ()

aka. not much.

so Dimitur can you try with debug versions which I think you alreayd have?

Dimitur also you say 'this is the fix [for notifical removal] but I cannot see what you mean. where is it?'

Gustavo, do you have any idea why this crash happens?

Yann, the problem is not that we do not send or reply though.

[dkirov]

@asterix: actually with nonblocking sockets we send and receive things, but we don't perform the gui operations. When removing modality we should do more checks. For example: "Relogin now" confirmation dialog should assume that acount may be offline when user clicks "Yes"

@nk: I said that the fix for notification removal is independent of modality problem and we should do the notification removal anyhow.

[nk]

so we have 3 things to work on:

a. find out why we crash? [debug-gtk] Dimitur?

b. fix notification removal

c. rm modality from dialogs that do not make sense to have it [such as MUC INV and FT REQ]. slaughter modality from allover is super bad. (violates GNOME HIG to name one) and should be done only if a. proves it is GTK philosophy or whatever bug. if it us, we see what we can do and as a super last resort we rm modality. at least this is my opinion and this makes sense to me as a more logical thing to do.

[asterix]

yes it's waht I meant: if we wait some minutes and then reply to invitation, all pending XML are treated then.

[dkirov]

@asterix: we can send and receive stanzas during the time this dialog is opened, only gui changes are performed after the modal dialog is closed.

We should split this ticket to two tickets. I don't think I should be assigned to the modality bug and I have many other things to do. Besides my opinion about these dialogs is clear.

[nk]

Dimitur, listen man. there are some dialogs which must be modal. nobody said we will release tomorrow. take your time, maybe even Gustavo knows. I thought you had debugging version of GTK and PyGTK that's why I thought of you

[asterix]

Nikos, listen man, When a dialog is modal, UI is not updated. So you don't see messages or events that comes in. You have to close the modal dialog to see all these events (maybe yo're no more connected or things like that). All is because we're blocked in run(). And as we're blocked in run() I'm not sur we parse incoming stanza and log cause we don't call connection.process() all is kepts in socket buffer I think. Am I wrong? This mean we don't log messages in DB.

[dkirov]

I didn't say I won't try to do something for the modality and crashes, I just cannot take responsibility for solving it and notification removal is totaly different ticket. It seems to me that making these (not all) dialogs nonmodal is the only possible solution.

We don't call connection.process() anymore, but we have some timeouts, which may not be called, for example read_sleepy, which will make us not available as a result of being idle. I may be wrong for the timeouts, but I'm sure for the stanzas.

Simple test. Open a modal dialog in one account and plug/unplug the network. You will see that account reconnects, e.g. it sends/receives stanza. No visible notification though.

[dkirov]

I remember that using weakrefs we can make a dependent window (not sure for the code, but it can be researched), this way we don't loose iteraction with the roster and still see the "modal" dialog on top.

[nk]

using weakrefs where?

guys, I do not understand why you do not get what I mean. Really! I agree with you that most dialogs must not be modal.

[jim++]

Asterix, indeed, messages beetween ft request and logout of contact (and crash) were NOT saved in db.

[dkirov]

on a nonmodal dialog:

dialog.set_modal(False)
dialog.set_transient_for(parent_window)
dialog.destroy_with_parent(True)

we need to test how many dialog references are kept.

this will make it dependent on parent_window, without preventing interaction with it. For example see nautilus, or epiphany about dialog. In gnome 2.14 preferences dialogs too.

This is what we need in almost all of the cases (IMO). The only exception I see is disk space dialog, if someone sees other dialogs that need to be modal, please put them down.

To change all dialogs is lots of work, which will need lots of testing and bug fixing. Maybe we can do it for version 0.10.1 ?

[nk]

doesn't transient result in window showing in the middle of the window?

anyways someone needs to test this, and if it's ok [it's also another ticket WM_TRANSIENT] then make a gtkgui_helper method taht would accept the dialog and set those

also it could mean that dialogs constructs should accept parent (atm it's hardocded to None)

no, if it's gonna happen it's for .10

anyways I take this job. do the rest:

a. find out why we crash? [debug-gtk]

b. fix notification removal

[dkirov]

position like center is determined from 'window-position' property. Transient has to do with 'parent' property

[nk]

http://www.pygtk.org/pygtk2reference/gtk-constants.html#gtk-window-position-constants

if you call set_transient_for it's set in the center which sucks. also it's not easy to determine our 'parent' window in our application.

please if you can gtk-debug and find out why this happens at least we have a clue before starting fixing and breaking stuff ending up nowhere.

c also #1024 (for another UI reason)

[dkirov]

gtk-doc:

Indicates to the window manager that window is a transient dialog associated with the application window parent. This allows the window manager to do things like center window on parent and keep window above parent.

set_transient, doesn't center the window!!! When you set position 'center' it is centered to the parent, specified by set_transient, not vice versa.

If property 'position' has default value 'center' you can still change it to None. However when things are up to the window manager, it is good to let it take the right decision.

Besides, it is a common practice in Gnome applications.

[dkirov]

@nk: a. find out why we crash? [debug-gtk] Somehow I miss the Gödel machine :)

[nk]

you fail to understand that we're not gedit which has one big window and can how whatever dialog in hte middle. you also fail to understand we're not nautilus for the same reason.

who will be our parent? do you like to see dialog centered in ROSTER? BLIAH {I've seen it so I know}

about Godel, I thought you said you were going to try. at least with debugging symbols we will have more which is the cause of the bug which is number #1 [know you problem] for fixing problems. unless you disagree with the steps on how to fix a problem ;)

[nk]

how ==> show

[asterix]

It once again seems that you don't read what dkirov wrote:

"set_transient, doesn't center the window!!!"

[nk]

gtk.Window.set_transient_for

def set_transient_for(parent)

parent : the parent window or None to remove the transient parent

The set_transient_for() method sets the window as a transient window for the window specified by parent. Dialog windows should be set transient for the main application window they were spawned from. This allows window managers to keep the dialog on top of the main window, or center the dialog over the main window. The gtk.Dialog() constructor and other convenience functions in PyGTK will sometimes call the set_transient_for() method on your behalf.

On Windows, this method will and put the child window on top of the parent, much as the window manager would have done on X.

if we're saying the same thing okay. else I read what everyone says so I do not like the attack for sure as I've said I have tried this for the other ticket and the result was SUCKING HARD

[nk]

also since I do not like the attack, and the best defense is the attack, I WOULD LIKE ANSWERS:

WHICH F$$$$$$G WIDGET will we set as parent? I've said some comments above and I don't see any replies other than accusations or repatation of ideas.

[asterix]

I give up .. if you don't understand what you're quoting I can't do more ... I don't know greek to translate for you.

parent widget will be our only main window, as suggested in the doc you quoted.

Also I remove gjc as I think he doesn't care about those child attack.

[nk]

Gustavo yea sorry man. he got CC for the bug of pending UI being activated all at once.

I never said you know Greek. See attach, I think we both 3 prefer coding to blabla.

about who is childish and who decides with 'latest comment' stuff and accuses I leave that to the public readers

[nk]

oh boy I'm centered

[nk]

in GNOME 2.12 [metacity WM] I get the dialog centered over the win. (parent is win)

so let's take a user case

I have roster hidden (or minimized), and I chat with my co-worker.

co-worker wants to send me a file. file-transfer is centered over the main window [eg the roster].

who doesn't understand and what, I'm welcome to discuss

[asterix]

not centered

[asterix]

see attachement. Of course I haven't moved the window before screenshot, believe me or not. So I can't test if main win is hidden cause I see no problem here. So feel free to hide main win before showing the dialog.

[nk]

yes. as I say in #1024 [which I can accuse you that you didn't read {but I wont so we can stop this trial talk :P}]

also it's super broken in most window managers

and I mean this, also I remember that that guy was in the room and I clearly explained to him that we were getting centered window under GNOME [our vast userbase], and he said 'yes I know..', so it's why I said in that ticket to make it ACE & False. I did not test the above attach in Windows nore KDE (with its default WM). but in GNOME 2.12 [about 2.14 that Dimitur said I cannot test atm] also I did not move win before saying that i'm centered [Yann I think we trust each other enough on this one so I don't need to provide a shot right? :) :)]

so to reposition our discussion,

one might say, ok FT req window afterall will die when #1205 is done.

so the problem remains iwth the rest of dialogs we popup which are of general information, not synched with current action user is doing.

For example, we can rm modality from invitation dialog [as we agreed one thousand comments above], but we cannot say we can replace this with transient as the problem is that it's hard to define a parent for that dialog. [dialog didn't come from user clicking on menuitem of a window]

so that inv dlg does not make sense to have transient, as if it has we cannot easily decide which place is the center of Gajim: [roster window [possibly hidden, or minimzed] or message window [possible hidden or minimized]]

as those problems have worried me more than once, I have come to the conclusion that such 'general notification about events' center can only be the *TRAYICON*. it is why I have proposed to assume trayicon availability and leave the geeks that run fooWM run a trayer. No I'm not innovator, and wake up nobody is in CompSci?. But I just like to observe. This idea come straight from the trayicon usage in many applications in Windows [and lately in GNOME {Rhythmbox}] with the Windows being the fucking best place for desktop apps [as correct me if I'm wrong, user cannot rm the trayicon "panel" so devs can depend that it is actually there].

So those general stuff, such as: "FOO invited you to ROOM BLA" or "Connection with Jabber.org lost" should *STICK* as notif-daemon popups under trayicon place, and if everyone cares for the ppl that don't have tray or don't have notif-daemon, maybe emulate this with old style notification [which I wrorte] with the exception that those window will not be hidden after FOO secs, and will only be hidden *after* user clicks on them, and that guarantees that user got that information [of connection lost]. This can actually happen and is VERY cool as latest notif-daemon allows buttons so we could show "Deny | Accept" for the invitation dlg and so on.

that way we solve:

a. modal problem

b. which is the parent window in any case?

and we're all happy and neat.

for the rest currently modal dialogs that come after *DIRECT* window interaction from user, we can for sure use transient and specify parent the window that user was interacting with.

that's all folks

[nk]

those notifications about general events of app that happen async etc, are very known to Windows users as 'balloon-style tooltip'

http://www.shellplus.com/examples/pics/ex_trayicon_demo.gif

in Linux world, we can do notification-daemon popups which belong to tray

http://trac.galago-project.org/attachment/ticket/21/Screenshot.png

and for people still not wanting to run a real Desktop Envrironment of 2006 I propose OUR old style notifications which will not timeout [as I've said in prev comment]

sth like this [only replace with our popups] {as they do not have notification-daemon}

http://rodrigo.gnome-db.org/shots/notification-daemon.png

if they have notification-daemon and they do not have tray, we fall back again to

http://rodrigo.gnome-db.org/shots/notification-daemon.png

so that way we are neat

now since most systems may not have notif-daemon .3 which can hold buttons, this means that dialog that also ask user action [such inv dialog] should have just the modality removed for the moment.

popup contain info about general event which user cannot interact with [but just hit close] {exmaple. con lost info [it's a ticket that we interrupt user too much about this] should definately use popup that stays forever. (see begining of this comment)

and last but not least IMO low disk space is a GNOME job to inform. as GNOME is the OS to the user eyes, not Gajim.

if I repeat myself, sorry but I really hope at least I Make myself clear

[nk]

arg I gave bad link for balloon-tooltip style under NOTIF-DAEMON

http://trac.galago-project.org/attachment/ticket/21/Screenshot.png?format=raw

now doesn't this look lovely? IT DOES IT DOES! :)

[asterix]

I think most of the problems are because of dialog.run() call cause we're stuck in that func until we reply to the dialog. Now ([5942]) most of that call are no more here, so it should be ok now.

[Jim++]

Still crash when ft request stay opened a long time :/

DEBUG: socket       got   <iq type='set' id='iChat_F0166B00' to='jim@jabber.fr/GaJim' from='biskot@illx.org/Maison, comme E.T.'>\n<si xmlns='http://jabber.org/protocol/si' id='sid_743F48DB' mime-type='binary/octet-stream' profile='http://jabber.org/protocol/si/profile/file-transfer'>\n<file xmlns='http://jabber.org/protocol/si/profile/file-transfer' xmlns:ichat='apple:profile:transfer-extensions' name='Donjon de Naheulbeuk 16.mp3' size='8301633' ichat:posixflags='000001A4'/>\n<feature xmlns='http://jabber.org/protocol/feature-neg'>\n<x xmlns='jabber:x:data' type='form'>\n<field type='list-single' var='stream-method'>\n<option>\n<value>http://jabber.org/protocol/bytestreams</value>\n</option>\n</field>\n</x>\n</feature>\n</si>\n</iq>

[messages and presences received]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212004672 (LWP 13042)]
0xb51f1671 in XmlPrologStateInitExternalEntity ()
   from /usr/lib/python2.4/site-packages/_xmlplus/parsers/pyexpat.so
(gdb) bt
#0  0xb51f1671 in XmlPrologStateInitExternalEntity ()
   from /usr/lib/python2.4/site-packages/_xmlplus/parsers/pyexpat.so
#1  0x089a4ac0 in ?? ()
#2  0xb5206540 in ?? ()
   from /usr/lib/python2.4/site-packages/_xmlplus/parsers/pyexpat.so
#3  0xbfe91fc8 in ?? ()
#4  0xb51de41f in XML_ParseBuffer ()
   from /usr/lib/python2.4/site-packages/_xmlplus/parsers/pyexpat.so
Previous frame inner to this frame (corrupt stack?)
(gdb)

[jim++]

ah ok ft request is still modal.

[dkirov]

Ft request dialog is no longer nonmodal

[dkirov]

Ft request dialog is no longer modal *