Could you maybe try to catch it ? http://sunsite.ualberta.ca/Documentation/Gnu/gdb-4.18/html_chapter/gdb_6.html gdb> handle SIGPIPE stop So we could see which thread is complaining. Thanks R On Thu, Mar 22, 2012 at 10:26 AM, Rein Couperus <rein@xxxxxxxxxxxx> wrote: > Here is the first example of wrong error handling in fldigi using the ARQ > interface: > > Program received signal SIGPIPE, Broken pipe. > 0x0012d422 in __kernel_vsyscall () > (gdb) > > When the error would be handled properly, the display would not freeze... > > BTW, when restarting the program, gdb says: > The program being debugged has been started already! > Do you want to start from the beginning? (y or n) y > > I guess this is a general problem related to all error handling in the ARQ > interface... > It also happens with errors in the socket and sound interfaces. > > Rein PA0R > > > > > > 1. If fldigi hangs, the display is not updated anymore (see attached > picture). > 2. I have run it under gdb before... the event log shows incoming ARQ > messages. > (e.g. mdde switching every minute). > > 3. Yes, you normally see outgoing messages in the output window. > 4. Either sound errors or rigctl socket errors. > 5. PI4TUE uses soft PTT via hamlib. > 6. PI4TUE uses the USB soundcard in the IC7200. > 7. Fldigi uses the USB sound driver of ubuntu 10.04 LTS. > > PI4TUE is now running under gdb. > > Rein PA0R > > > > "It only happens when using the ARQ interface for pskmail." > > Ah, ok, I never used this part. I have to investigate a bit the code. > Extra questions please: > > "It is always related to PTT (fldigi starts sending)." > > That is: jPSKMail sends a message through the ARQ interface. And the > problem happens sometimes only ? > > "The thread running X stops, most other threads (e.g. the ARQ thread) > still work." > > (1) The display is frozen ? > (2) How do you know the other threads are running ? Do they answer ? > (3) When jPSKMail can succesfully send through the ARQ interface, is there > anything visible on the X display, apart from the normal TX red spot ? And > is the red spot visible ? > > (4) "I will start PI4TUE under gdb, " > > User PI4TUE mentionned in > https://docs.google.com/spreadsheet/ccc?key=0ApD_rVrTY8hNdGc4alVqelRMY3BxR1RfeDdvUTJXOXc#gid=0 > > "E: trx_trx_receive loop: Sound error: Connection timed out." > > Any other detail about this specific problem ? (This is called precisely > when transmitting). > > Aprt from running gdb, can someone do it under valgrind ? (Which detects > uninitialised variables). > > Something interesting in the log window ? > > Thanks > > R > > > On Wed, Mar 21, 2012 at 4:37 PM, Rein Couperus <rein@xxxxxxxxxxxx> wrote: > >> It only happens when using the ARQ interface for pskmail. >> It also happens with hamlib, I never tried rigcat. >> It is mainly happening with the pskmail server. The server does NOT use >> the xmlrpc interface. >> It is always related to PTT (fldigi starts sending). >> The thread running X stops, most other threads (e.g. the ARQ thread) >> still work. >> I will start PI4TUE under gdb, to show what happens. >> As far as I can remember it just says thread 'xxx' stopped. >> >> Rein PA0R >> >> >> >> >> I do not use rigcat, just hamlib. Maybe this is the reason why the very >> rare problems I had had nothing to do with yours. >> >> Some questions please. >> >> (1) Could someone please try to do the same tests without rigcat ? >> >> (2) I am about to commit a new version which can create a core dump when >> receiving a signal (And with the correct environment variable). When >> available, it would be nice if some used it and tried to reproduce the >> problem. >> >> Cheers >> >> R >> >> On Wed, Mar 21, 2012 at 2:51 PM, Pär Crusefalk <per@xxxxxxxxxxxx> wrote: >> >>> Hi Eric, >>> >>> I have no solution for you, just wanted to let you know that you are not >>> alone in experiencing this. I tried to debug and find the cause a while >>> ago and came as far as pointing the finger at PTT handling in rigcat >>> (which is used even if rigcat is not used). I also tried to gather >>> information about other affected stations to see if we had something in >>> common that triggers the issue. Can't say I found any smoking gun there >>> but you are more than welcome to add your data to our finds: >>> http://goo.gl/6vNPT >>> >>> The bottom line is that fldigi has had this issue a long time and >>> nothing is being done about it. The way ahead for us is likely that we >>> get rid of fldigi and move to a java based modem. >>> >>> 73 de Per. sm0rwo >>> >>> >>> >>> >>> >>> Eric Davenport skrev 2012-03-21 15:40: >>> > Good Morning, >>> > >>> > I have been working with fldigi+jpskmail for some time. >>> > >>> > I have been trying to find an energy efficient way of running a server >>> > so I have been working on virtual machines and standalone computers for >>> > a while. >>> > >>> > I first tried to install it on Ubuntu 10 on a VM Server I gave up when >>> I >>> > could not get the Signalink USB to transfer any information. Same >>> > situation using VirtualBox. >>> > >>> > So now I am trying a Laptop running Ubunto 10.04 fldigi 3.21.40 from >>> > source and using fltk 1.3. >>> > >>> > So to test it I am using jPSKMAIL 1.5.7 >>> > >>> > I am running fldigi minimized but that does not seem to be the problem. >>> > >>> > This works for 2 or 3 hours and fldigi freezes. >>> > >>> > Nothing in the Logs anywhere it just stops. >>> > >>> > Maybe this is related to running jPSKMAIL and would not happen with the >>> > server. >>> > >>> > When I ran server some years ago I do not recall any problems and it >>> ran >>> > on a much slower machine at the time for weeks on end. >>> > >>> > I have seen references by Rein and others to freezing and wonder if >>> > their is something I need to change that I do not remember. >>> > >>> > Maybe I should just get the server up and running and see if that >>> freezes. >>> > >>> > Any suggestions are appreciated. >>> > >>> > Eric >>> > >>> >>> >>> -- >>> Mobile: +46703784299<#13639f149980f9cc_13636b936a6b730c_136361ee36ac5f36_> >>> >> >> >