[pskmail] Re: Aw: Re: Fldigi crash...
- From: Jack Chomley <radio@xxxxxxxxxxxx>
- To: "pskmail@xxxxxxxxxxxxx" <pskmail@xxxxxxxxxxxxx>
- Date: Mon, 23 Apr 2012 18:35:56 +1000
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:
