Intermitent application crash occurs when using NRComm1.Active:=False; statement

[iswinks]

As per the subject I am gettign an intermitent application crash occurs when using "NRComm1.Active:=False;" statement in my Enbarcadero Delphi 2010 application. 

I am using the nrComm Lib v9.08 trial unit. The precice error message is "access violation at 0x0040a6ce: read address of 0x00000000'. Process stopped. Use Step or Run to continue.

The debugger stops with the following ASM code, with the error at the top line.

0040A6CE 8B0482              mov eax,[edx+eax*4]
0040A6D1 C3                    ret
0040A6D2 E89DFFFFFF       call InitThreadTLS
0040A6D7 A1E4294E00       mov eax,[$004e29e4]
0040A6DC 50                    push eax
0040A6DD E86EFFFFFF       call TlsGetValue
0040A6E2 85C0                 test eax,eax
0040A6E4 7401                 jz $0040a6e7
0040A6E6 C3                    ret
0040A6E7 A1447C4E00       mov eax,[$004e7c44]
0040A6EC C3                    ret

My usage of the comm unit is extremely simple. My configuration of NRcomm1 is as follows:
Baude Rate   38400
BufferInSize   1024
BufferOutSize   1024
ByteSize   8
Comport      cpCOM1
ComPortNo   1

EnumPorts   epQUickAll
EventChar   #0

ModemSignals   All greyed out
MonitorCTS   Notused
MonitorDSR   Notused
MonitorRing   Notused
MonitorRLSD    Notused
Name      nrComm1
Parity      pNone
RS485Mode   False
StopBits   One
StreamProtocol   spNone
Tag      0
TerminalEcho   True
TerminalUsage   tuNone
TimeoutRead   0
TimeoutWrite   100
TraceStates   [tsRxChar]
tsRxChar   True
All others false
UseMainThread   True


The program uses the nrComm1.SendString('c'); command to send the 'c' charactor to a serial attached device.  I then initiate a timer that waits 1500ms before it declares a communications timeout.

I use the OnAfterReceive event to capture incoming data. If data is received, the TimeoutTimer is disabled, and the data is processed.  Then a whole manner of other instructions and communication events run.

If a timeout does happen, a timeouttimer event is run. This event clears some variables and then turns off the serial port with the nrComm1.Active:=False command.  After a 1000ms delay another timer re-opens the serial port and it repeats the sending 'C' process.

The crash error only occurs randomly, and only when timeouts occur. When the communication is correctly established to my serial device and no timeouts occur, the application runs flawlessly.

The error happens when the code is being run on a windows vista or windows xp machine, both are 32bit OS's. The random nature of the error means it can happen after 5 timeouts or 50.

Is there perhaps a better way to setup the serial port to operate in a blind, no flow control method that will work around this error?

Cheers,
Ian

[iswinks]

I'll add, that both machines ive tested my application on that display the same error are using on board RS232 ports, and not USB serial ports.

One is a hp laptop, the other is a gigabyte GA965 motherboard.

[Roman Novgorodov]

Hello

Thank you for your information.

The assembler code is not from NrComm sources.

If you are using your own timeouts for freeze main thread I can recommend you to set UseMainThread property in False and try again.

Roman Novgorodov
DeepSoftware.Com

[iswinks]

Sorry that hasnt fixed the crash error...

To completely eliminate my code I went back to one of your examples, the VT100 example that uses the nrComm & nrLogFile objects.

Without changing the code as supplied with the unit at all I can generate the same error by clicking the Checkbox1, which is used to toggle the nrComm1.Active status.

The random/intermittent nature of the error is still present. It doesnt crash immediatly, but clicking it repeatadly causes the crash to occur.  The enable/disable function as caused by the clicking is essentially the same as what my timer process is doing every 1.5 seconds in my code.

Do you have another suggestion to try?

[iswinks]

I have also tried setting my timer interval to 10 seconds (which is impractical for the program I am writing but acceptable for diagnosing this problem), and the error still happens.

Try adding a timer object that toggles the activation of the nrComm object to your VT100 example... hopefully you can replicate the problem.

[Roman Novgorodov]

Hello

Please create SIMPLE project that crashes and send to me it sources.
You can upload it here.

We will try to reproduce on our side.

Roman Novgorodov
DeepSoftware.Com

[iswinks]

Hi Roman,

Here is the modified code from your vt100 example that ships with 9.08 of nrComm. When the application is started select a com port and tick the box. The timer will then toggle on and off the checkbox, and active/inactive the nrComm object.  The crash occurs usually before 30 seconds.

I hope you can fix this!

Cheers,
Ian

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, nrclasses, nrcomm, StdCtrls, nrcommbox, nrterminal, ExtCtrls,
  nrlogfile;

type
  TForm1 = class(TForm)
    Panel1: TPanel;
    CheckBox1: TCheckBox;
    Button1: TButton;
    nrTerminal1: TnrTerminal;
    nrDeviceBox1: TnrDeviceBox;
    nrComm1: TnrComm;
    nrLogFile1: TnrLogFile;
    Timer1: TTimer;
    procedure CheckBox1Click(Sender: TObject);
    procedure Button1Click(Sender: TObject);
    procedure Timer1Timer(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.CheckBox1Click(Sender: TObject);
begin
  nrComm1.Active := CheckBox1.Checked;
  timer1.Enabled:=True;
end;

procedure TForm1.Timer1Timer(Sender: TObject);
begin
  if CheckBox1.checked then
    CheckBox1.Checked:=False
  Else
    CheckBox1.Checked:=True;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  nrComm1.ConfigDialog;
end;

end.

[Roman Novgorodov]

Hello

Thank you for your information.

It seems you are right.
There is a problem.

In Delphi7 all works well without crashing, but under Delphi 2010 app crashes.

We will try to catch and fix problem.

Roman Novgorodov
DeepSoftware.Com

[Roman Novgorodov]

Hello

We have tried to correct problem.

Please test on your side and let me know results:

http://www.nrcommlib.com/nrcomm910beta.zip

Roman Novgorodov
DeepSoftware.Com

[iswinks]

Hi Roman,

The new version is an improvement on 9.08 but the problem isnt 100% fixed just yet. I have recompiled my code and have run both the applications on my vista and winxp machines for an extended period of time to test the new version.  The tests have been run connected to the serial device to test the comms routines are still stable, and also disconnected, to test the "fix" you have implemented to stop the crash when the port is opened and closed.

The application appears stable in both connected and disconnected states on the windows xp SP3 machine and has for the moment survived over 1300 nrComm.active enable/disable toggles, and about 25000 data packet reads from the serial device. The hardware is a single core celeron 1.4ghz laptop with 500mb ram.
over 9500 timeouts, and no errors reported.


The same code running on the vista machine appears much stable now too, but it still crashes. This time with a different error, and different simptom. The error happened after 3466 RS232 timeout events.

The error that is reported now is as follows:

Project Program1.exe raised exception class Exception with message "Decice "COM1" Open error !!! Access is denied".


I have taken a screen shot of the debugger code in delphi. See the attached picture.

[Roman Novgorodov]

Hello

Thank you for your information.

The your source code above has no read-write operations or timeout waitings.
Can you upload sources of new test application that demonstrates crash and we will try on our side.

Serial port driver returns Access denied error if com port is still busy or already opened.

Roman Novgorodov
DeepSoftware.Com

[iswinks]

Hi Roman,

Ive been continuing testing with the new version of the unit, and my combiled code continues to be solid and stable on the WinXP platform.

Give me a few more days to continue testing. I want to run the same code on my Windows Vista laptop (once its back from repair) for a while to try and isolate if the crash I am still getting is a Vista issue, or possibly something to do with a dual core HT processor issue.

I'll keep you informed.