Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[pmpfe]

Hi there, and please excuse me if this is posted in the wrong section, as it is not actually a crash, but a hang.

My amule seems to hang sometimes, freezing. The 'ps' utility shows a parent amule on R ("on run queue") and a child amule on S ("sleeping").
When I tried to gdb the processes, the parent was blocked on a select and the child blocked on an "fts_children" function.

Does anyone have any hint on what may be going on?

Thanks in advance,
Paulo

[deltaHF]

hi,

tell us more about your pc .. which wxgtk version etc. and maybe run your amule in gdb -> http://www.amule.org/wiki/index.php/Backtraces

cheers

[pmpfe]

Originally posted by deltaHF
tell us more about your pc .. which wxgtk version etc. and maybe run your amule in gdb -> http://www.amule.org/wiki/index.php/Backtraces
cheers

wxgtk-2.4-config, wxbase-config and wx-config all yield version 2.4.2.

Here's the output of ldd on my amule binary.

I'll post a full gdb backtrace as soon as the freezing occurs again (I'll leave it running tonight and in the morning it will probably be frozen).

Thanks again,
Paulo

[ken]

In the case of a freeze (as opposed to a crash), all threads may be of interest, so you might want to do:

thread apply all bt

Thanks for your help.

[pmpfe]

Here's a bt of the child amule (bt full doesn't give extra information (it says no symbol table info available, even though my amule was compiled with debugging information. I assume it is because all functions in backtrace tree are not part of amule code.))

'thread apply all bt' does not seem to do anything, but I'll keep executing it before producing further backtraces.

(gdb) bt
#0  0x40aa27a2 in fts_children () from /lib/libc.so.6
#1  0x40aa286c in poll () from /lib/libc.so.6
#2  0x400319c0 in pthread_detach () from /lib/libpthread.so.0
#3  0x40aab037 in clone () from /lib/libc.so.6
(gdb)

The parent process bt is longer, so I've put it here. I should mention that "reloadaIPF", a function that is part of the backtrace, is a simple two liner I put in amuleDlg.cpp to handle the USR1 signal, so that I can have amule reload the filters at scheduled times.
Here's the code for the function.

Code: [Select]

void reloadaIPF(int i){
        theApp.ipfilter->Reload();
        theApp.clientlist->FilterQueues();
}
Is this wrong? Is there a problem with applying a filter reload like this? Please let me know if it was two naiv of me to think I could get by with something this simple.

Incidentally, an actual crashed occurred today, which might not even be related to this ipf reloading problem, the bt for which I've put here.

Sorry for the pile of confusion, and thanks again in advance for any hints you might have.

Paulo

[GonoszTopi]

Seems to me that your reloadIPF() function might be responsible for the hang.

A nicer, and "officially supported" way of reload ipfilter at scheduled times is with amulecmd, just issue "amulecmd -f -c reloadipf" from cron. Afaik it can be compiled with wxBase-2.4.2 too, you just have to add --enable-amulecmd to your configure flags.

[Kry]

Do you call that function from a thread?

[ken]

Originally posted by pmpfe
'thread apply all bt' does not seem to do anything, but I'll keep executing it before producing further backtraces.

Nevermind, then.  It shouldn't be executed "before" backtraces, it should produce the backtraces itself.  In other words, one would use it instead of just plain "bt".  However, if it does nothing, then it must be a difference between our versions of gdb.  Sorry about the blind alley.  

[pmpfe]

Originally posted by GonoszTopi
Seems to me that your reloadIPF() function might be responsible for the hang.
A nicer, and "officially supported" way of reload ipfilter at scheduled times is with amulecmd, just issue "amulecmd -f -c reloadipf" from cron. Afaik it can be compiled with wxBase-2.4.2 too, you just have to add --enable-amulecmd to your configure flags.

Unfortunately, as I understand, the reloadipf for amulecmd does not filter the queue after filter reload (which is something I need). The strange thing is that if I remove the queue filtering it seems to become a lot more stable (hasn't crashed or frozen for 13 straight hours now, though I remember it crashed in a former version where I did not have the queue filtering part).

ken: thanks for the hint anyways, if I happen to find myself debugging a threaded app one of these days it might come in handy

Originally posted by Kry
Do you call that function from a thread?

No, I install the function as a signal handler and it runs in response to shell kill commands. I have

Code: [Select]

signal(SIGUSR1, reloadaIPF); in amuleDlg.cpp just after the signal(SIGPIPE, SIG_IGN).

Paulo

EDIT: Happy new year

[pmpfe]

The hang occured again (this time without queue filtering on filter reload). The new bts are here.

Paulo