locked : Logging failure


ralfvoepel@...
 

Hi Mike,
I have the same setup and had the same problem. For some reason the communicator from Log4OM did not autostart. I always make sure it is running. Sometimes I have to stop and restart the communicator if it "misbehaves".
That fixed my problem.

73,
de KF5WGB - Ralf


Michael Black
 

Nope...not a communicator problem....not 100% sure but seems to happen after being on overnight and 1st QSO of day.
I've tracked down some possible problems and am testing a potential fix from Laurie now but may take a week or so before I'd call it "fixed" since it doesn't happen very often.

It's definitely not Log4OM's problem and this problem should show up on other loggers too.  But if you are the kind of operator that restart things every day you may not see the behavior.  I keep mine running 24x7.

de Mike W9MDB



From: "ralfvoepel@... [HamApps]"
To: HamApps@...
Sent: Tuesday, January 24, 2017 5:43 PM
Subject: [HamApps] Re:: Logging failure

 
Hi Mike,
I have the same setup and had the same problem. For some reason the communicator from Log4OM did not autostart. I always make sure it is running. Sometimes I have to stop and restart the communicator if it "misbehaves".
That fixed my problem.

73,
de KF5WGB - Ralf



Joe Subich, W4TV
 

It's definitely not Log4OM's problem and this problem should show up
on other loggers too.
I have never seen the problem with JTAlert and DXKeeper.

I keep mine running 24x7.
I find that JTAlert (the last two or three versions) will hang if left
running 24 x 7. Often after the computer has been idle (monitoring)
for several hours. When I notice the hang, it becomes necessary to
use Task Manager to end task and restart JTAlert.

73,

... Joe, W4TV


On 1/25/2017 8:03 AM, Black Michael mdblack98@yahoo.com [HamApps] wrote:
Nope...not a communicator problem....not 100% sure but seems to happen after being on overnight and 1st QSO of day.I've tracked down some possible problems and am testing a potential fix from Laurie now but may take a week or so before I'd call it "fixed" since it doesn't happen very often.
It's definitely not Log4OM's problem and this problem should show up on other loggers too. But if you are the kind of operator that restart things every day you may not see the behavior. I keep mine running 24x7.
de Mike W9MDB

From: "ralfvoepel@gmail.com [HamApps]" <HamApps@yahoogroups.com.au>
To: HamApps@yahoogroups.com.au
Sent: Tuesday, January 24, 2017 5:43 PM
Subject: [HamApps] Re:: Logging failure

Hi Mike,
I have the same setup and had the same problem. For some reason the communicator from Log4OM did not autostart. I always make sure it is running. Sometimes I have to stop and restart the communicator if it "misbehaves".
That fixed my problem.

73,
de KF5WGB - Ralf


Michael Black
 

If you get a hang send in your session files via ?/Contact Support after you restart.
I would think if this was common would've seen it mentioned on the list

de Mike W9MDB
 



From: "'Joe Subich, W4TV' lists@... [HamApps]"
To: HamApps@...
Sent: Wednesday, January 25, 2017 7:13 AM
Subject: Re: [HamApps] Re:: Logging failure

 

> It's definitely not Log4OM's problem and this problem should show up
> on other loggers too.

I have never seen the problem with JTAlert and DXKeeper.

> I keep mine running 24x7.

I find that JTAlert (the last two or three versions) will hang if left
running 24 x 7. Often after the computer has been idle (monitoring)
for several hours. When I notice the hang, it becomes necessary to
use Task Manager to end task and restart JTAlert.

73,

... Joe, W4TV

On 1/25/2017 8:03 AM, Black Michael mdblack98@... [HamApps] wrote:
> Nope...not a communicator problem....not 100% sure but seems to happen after being on overnight and 1st QSO of day.I've tracked down some possible problems and am testing a potential fix from Laurie now but may take a week or so before I'd call it "fixed" since it doesn't happen very often.
> It's definitely not Log4OM's problem and this problem should show up on other loggers too. But if you are the kind of operator that restart things every day you may not see the behavior. I keep mine running 24x7.
> de Mike W9MDB
>
> From: "ralfvoepel@... [HamApps]"
> To: HamApps@...
> Sent: Tuesday, January 24, 2017 5:43 PM
> Subject: [HamApps] Re:: Logging failure
>
> Hi Mike,
> I have the same setup and had the same problem. For some reason the communicator from Log4OM did not autostart. I always make sure it is running. Sometimes I have to stop and restart the communicator if it "misbehaves".
> That fixed my problem.
>
> 73,
> de KF5WGB - Ralf



Laurie, VK3AMA <groups08@...>
 

On 26/01/2017 12:13 AM, 'Joe Subich, W4TV' lists@subich.com [HamApps] wrote:
I find that JTAlert (the last two or three versions) will hang if left
running 24 x 7. Often after the computer has been idle (monitoring)
for several hours. When I notice the hang, it becomes necessary to
use Task Manager to end task and restart JTAlert.

73,

... Joe, W4TV
Joe,

This is the first I have heard of this consistent hanging behaviour. Hard to guess the root cause if it has been happening for the last few versions. If I knew definitively which version started exhibiting this behaviour I might be able to identify a probable cause.

There are several high-use JTAlert users running multiple instances 24x7 that are not reporting this sort of consistent hang.

There has been some problematic behaviours creeping into JTAlert over the last year or so. The only consistency with the reports is that the behaviours are random, affecting different parts of JTAlert operation, different Windows versions, often erroneous non-declared variable errors or code line numbers, only affecting a small number of users and non-reproducable in a test environment.

I have long suspected the Compiler used for JTAlert is the root-cause. I am pushing its limits and the number of hacks and workarounds to overcome many if its limitations (single-threaded, non-object oriented constructs, no support for async functions, uses old pre Win8 API calls) has been increasing. This is why I am currently working on JTAlert V3, a total rewrite of the code using a modern object-orientated language/development environment.

Sorry, unless I identify a definitive cause of the hangs, they are likely go unresolved.

de Laurie VK3AMA


Joe Subich, W4TV
 

Laurie,

If I knew definitively which version started exhibiting this
behaviour I might be able to identify a probable cause.
Unfortunately, I did not note when the behavior began as I assumed
it was being generated by issues with the beta and RC versions of
WSJT-X 1.7.0 that I was using.

Sorry, unless I identify a definitive cause of the hangs, they are
likely go unresolved.
I have sent you session logs that followed a crash that occurred while
I was away during the mid portion of today. As typically happens,
JTAlertX stopped responding to anything other than the window controls
while I was away and the only course of action was to close the
Window [X] and then use Task Manager to end the remaining background
task (Audio & Visual Alerts for WSJT-x and JT65-HF).


73,

... Joe, W4TV


On 1/25/2017 4:33 PM, 'Laurie, VK3AMA' groups08@vkdxer.com [HamApps] wrote:


On 26/01/2017 12:13 AM, 'Joe Subich, W4TV' lists@subich.com [HamApps] wrote:
I find that JTAlert (the last two or three versions) will hang if left
running 24 x 7. Often after the computer has been idle (monitoring)
for several hours. When I notice the hang, it becomes necessary to
use Task Manager to end task and restart JTAlert.

73,

... Joe, W4TV
Joe,

This is the first I have heard of this consistent hanging behaviour.
Hard to guess the root cause if it has been happening for the last few
versions. If I knew definitively which version started exhibiting this
behaviour I might be able to identify a probable cause.

There are several high-use JTAlert users running multiple instances 24x7
that are not reporting this sort of consistent hang.

There has been some problematic behaviours creeping into JTAlert over
the last year or so. The only consistency with the reports is that the
behaviours are random, affecting different parts of JTAlert operation,
different Windows versions, often erroneous non-declared variable errors
or code line numbers, only affecting a small number of users and
non-reproducable in a test environment.

I have long suspected the Compiler used for JTAlert is the root-cause. I
am pushing its limits and the number of hacks and workarounds to
overcome many if its limitations (single-threaded, non-object oriented
constructs, no support for async functions, uses old pre Win8 API calls)
has been increasing. This is why I am currently working on JTAlert V3, a
total rewrite of the code using a modern object-orientated
language/development environment.

Sorry, unless I identify a definitive cause of the hangs, they are
likely go unresolved.

de Laurie VK3AMA



------------------------------------
Posted by: "Laurie, VK3AMA" <groups08@vkdxer.com>
------------------------------------


------------------------------------

Yahoo7 Groups Links




Seb
 

I have one computer with an SDR that runs the latest versions of WSJT-X and JTAlertX. This PC is never shut off, runs on a UPS and for the most part has been up for months.

I have yet to see any lockups or crashes on either program.

73 de Sebastian, W4AS

On Jan 25, 2017, at 5:04 PM, 'Joe Subich, W4TV' lists@subich.com [HamApps] <hamapps@yahoogroups.com.au> wrote:


Laurie,

If I knew definitively which version started exhibiting this
behaviour I might be able to identify a probable cause.
Unfortunately, I did not note when the behavior began as I assumed
it was being generated by issues with the beta and RC versions of
WSJT-X 1.7.0 that I was using.

Sorry, unless I identify a definitive cause of the hangs, they are
likely go unresolved.
I have sent you session logs that followed a crash that occurred while
I was away during the mid portion of today. As typically happens,
JTAlertX stopped responding to anything other than the window controls
while I was away and the only course of action was to close the
Window [X] and then use Task Manager to end the remaining background
task (Audio & Visual Alerts for WSJT-x and JT65-HF).


73,

... Joe, W4TV


On 1/25/2017 4:33 PM, 'Laurie, VK3AMA' groups08@vkdxer.com [HamApps] wrote:


On 26/01/2017 12:13 AM, 'Joe Subich, W4TV' lists@subich.com [HamApps] wrote:
I find that JTAlert (the last two or three versions) will hang if left
running 24 x 7. Often after the computer has been idle (monitoring)
for several hours. When I notice the hang, it becomes necessary to
use Task Manager to end task and restart JTAlert.

73,

... Joe, W4TV
Joe,

This is the first I have heard of this consistent hanging behaviour.
Hard to guess the root cause if it has been happening for the last few
versions. If I knew definitively which version started exhibiting this
behaviour I might be able to identify a probable cause.

There are several high-use JTAlert users running multiple instances 24x7
that are not reporting this sort of consistent hang.

There has been some problematic behaviours creeping into JTAlert over
the last year or so. The only consistency with the reports is that the
behaviours are random, affecting different parts of JTAlert operation,
different Windows versions, often erroneous non-declared variable errors
or code line numbers, only affecting a small number of users and
non-reproducable in a test environment.

I have long suspected the Compiler used for JTAlert is the root-cause. I
am pushing its limits and the number of hacks and workarounds to
overcome many if its limitations (single-threaded, non-object oriented
constructs, no support for async functions, uses old pre Win8 API calls)
has been increasing. This is why I am currently working on JTAlert V3, a
total rewrite of the code using a modern object-orientated
language/development environment.

Sorry, unless I identify a definitive cause of the hangs, they are
likely go unresolved.

de Laurie VK3AMA


Laurie, VK3AMA <groups08@...>
 

Joe,

I could not find anything of significance in your session files. This is not unexpected. For performance/responsiveness reasons, JTAlert caches its debug data in memory and flushes it to disk periodically. Once JTAlert hangs (and needs to be killed) any cached records are lost as they are never written to disk. Whether the hang actually generates an error that JTAlert captures is unknown, I suspect not as whatever the cause is fatal.

Does your Windows EventViewer show any JTAlert specific entries?

de Laurie VK3AMA
   


On 26/01/2017 9:04 AM, 'Joe Subich, W4TV' lists@... [HamApps] wrote:
I have sent you session logs that followed a crash that occurred while
I was away during the mid portion of today. As typically happens,
JTAlertX stopped responding to anything other than the window controls
while I was away and the only course of action was to close the
Window [X] and then use Task Manager to end the remaining background
task (Audio & Visual Alerts for WSJT-x and JT65-HF).

73,

... Joe, W4TV


Joe Subich, W4TV
 

Nothing in Windows Event Viewer that tags JTAlert.

73,

... Joe, W4TV

On 1/26/2017 7:28 PM, 'Laurie, VK3AMA' groups08@vkdxer.com [HamApps] wrote:


Joe,

I could not find anything of significance in your session files. This is not
unexpected. For performance/responsiveness reasons, JTAlert caches its debug
data in memory and flushes it to disk periodically. Once JTAlert hangs (and
needs to be killed) any cached records are lost as they are never written to
disk. Whether the hang actually generates an error that JTAlert captures is
unknown, I suspect not as whatever the cause is fatal.

Does your Windows EventViewer show any JTAlert specific entries?

de Laurie VK3AMA


On 26/01/2017 9:04 AM, 'Joe Subich, W4TV' lists@subich.com [HamApps] wrote:
I have sent you session logs that followed a crash that occurred while
I was away during the mid portion of today. As typically happens,
JTAlertX stopped responding to anything other than the window controls
while I was away and the only course of action was to close the
Window [X] and then use Task Manager to end the remaining background
task (Audio & Visual Alerts for WSJT-x and JT65-HF).

73,

... Joe, W4TV