[pskmail] Re: Aw: Re: Fldigi crash...
- From: Bernard Dekok <kc9sgv@xxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Mon, 23 Apr 2012 07:34:33 -0500
So sorry to hear that, Jack.
I had several crashes in FLDigi over the weekend testing the new JD3 modes
using only FLDigi.
(Not running PSKMail.)
The crashes all occurred when I terminated the transmission while
transmitting large text files.
The waterfall just froze, and I could not close FLdigi.
Had to reboot the computer every time.
Did this from both a Windows and Ubuntu OS.
The Ubuntu FLDigi crashed more often....
The PSK 500 and PSK 500R map pairings worked excellently.
THOR 88 did not want to cooperate. Could not get it to decode....
KC9SGV
On Mon, Apr 23, 2012 at 3:35 AM, Jack Chomley <radio@xxxxxxxxxxxx> wrote:
> Rein,
>
> I would like to, if I had the knowledge history that you have with
> PSKmail, but since I have Cancer.......I will die, before I could get it
> finished.........
>
> 73,
>
> Jack VK4JRC
>
> Sent from my iPad
>
> On 23/04/2012, at 6:25 PM, "Rein Couperus" <rein@xxxxxxxxxxxx> wrote:
>
> Unfortunately, this hardware would be useless without software...
>
> But it is open source, so go ahead and surprise us....
>
> Rein PA0R
>
> .
> Rein,
>
> Build it, in hardware....... :-)
>
> 73,
>
> Jack VK4JRC
>
>
>
> Sent from my iPad
>
> On 23/04/2012, at 5:28 PM, "Rein Couperus" <rein@xxxxxxxxxxxx> wrote:
>
> I have spent the last 2 weeks hunting for the problem in the
> fldigi/jpskmail combination.
>
> I have changed the server to incorporate lots of debugging routines
> to catch the errors...
>
> I have found an ultra-seldom race condition in the interface handler for
> ARQ,
> and fixed it.
>
> I have run the test software on PI4TUE during the weekend, and it looked
> good.
>
> This morning I found both server and fldigi running, but clearly fldigi
> had stopped
> servicing the ARQ socket, and also the display was frozen.
>
> The server could still write to fldigi, so the socket was still alive at
> the fldigi side.
> I guess the misc/arqio routine had crashed...
>
> I am now stopping work on this, it is costing too much of my time. I am
> now
> waiting for the fldigi people to take action.
>
> Here is the backtrace (fldigi still running, but display and ARQ socket
> not being
> serviced):
>
> 0x0012d422 in __kernel_vsyscall ()
> (gdb) bt
> #0 0x0012d422 in __kernel_vsyscall ()
> #1 0x0022b245 in sem_wait@@GLIBC_2.1 ()
> from /lib/tls/i686/cmov/libpthread.so.0
> #2 0x081a2f83 in trx_wait_state () at trx/trx.cxx:640
> #3 0x0809b67d in init_modem_sync (m=42, f=0) at dialogs/fl_digi.cxx:1242
> #4 0x080f9f00 in __call<, 0, 1> (this=0xb75baf88, run=true)
> at /usr/include/c++/4.4/tr1_impl/functional:1137
> #5 operator()<> (this=0xb75baf88, run=true)
> at /usr/include/c++/4.4/tr1_impl/functional:1191
> #6 func_wrap<std::tr1::_Bind<void (*()(int, int))(int, int)>
> >::destroy(bool)
> (this=0xb75baf88, run=true) at ./qrunner/fqueue.h:48
> #7 0x0816756b in fqueue::pop (fd=17, arg=0x82f72f0) at qrunner/fqueue.h:96
> #8 fqueue::execute (fd=17, arg=0x82f72f0) at qrunner/fqueue.h:102
> ---Type <return> to continue, or q <return> to quit---
> #9 qrunner::execute (fd=17, arg=0x82f72f0) at qrunner/qrunner.cxx:106
> #10 0x002c2ad0 in fl_wait(double) () from /usr/lib/libfltk.so.1.1
> #11 0x00270b6b in Fl::wait(double) () from /usr/lib/libfltk.so.1.1
> #12 0x00270ce4 in Fl::run() () from /usr/lib/libfltk.so.1.1
> #13 0x080f2d11 in main (argc=1, argv=0xbffff494) at main.cxx:460
> (gdb)
>
> The event log was still alive, but only output RSID notifications...
> I am really getiing fed up with this, and will pursue the V2 modem route...
>
> Rein PA0R
>
>
>
> --
> http://pa0r.blogspirit.com
>
>
>
Other related posts:
