Script which works in SC v5.19, crashes in v6.05

[Anonymous]

Hi Stefan,

I have script which works very fine in v5.19 and recently I've tried to jump to newest version but unfortunately script crashes :(

Let's start with some details:
- Script crashes in radom moments after opening serial port and starting communication with external board
- Exchanged frames are quite small, around 10-20 bytes which are similar like AT modem commands, and exchange is done as request-response in one function (send, wait for sending, wait, try to get response)
- I've narrowed problematic places to (probably) 2 functions: waitForBytesWritten() within TX handler and sleepFromScript() (currently just sleep()).

• When I run ScriptCommunicator.exe in compatibility mode for win8 (I have win10) script doesn't crash anymore but then script behaves very strange:
  • waitForBytesWritten() randomly returns false (even if only several bytes are in buffer) and from that point doesn't send anything anymore. Function bytesToWrite() starts returning only growing output buffer and waitForBytesWritten() returns always false, errorString() return always timeout error).
  • It helps to reopen port again and put frame again with writeString() function

Here are few error read in visual studio (after crash of ScriptCommunicator.exe):

Unhandled exception at 0x00007FF897F3AFCF (msvcrt.dll) in ScriptCommunicator.exe: 0xC0000005: Access violation reading location 0x0000000000000004.
Unhandled exception at 0x00007FF899247173 (ntdll.dll) in ScriptCommunicator.exe: 0xC0000374: A heap has been corrupted (parameters: 0x00007FF89929D6B0).
Unhandled exception at 0x00007FF897F83DE0 (msvcrt.dll) in ScriptCommunicator.exe: 0xC0000005: Access violation reading location 0x000002004DF0C000.
Unhandled exception at 0x00007FF897F83DE0 (msvcrt.dll) in ScriptCommunicator.exe: 0xC0000005: Access violation reading location 0x0000018B091DE000.
Unhandled exception at 0x00007FF897F83DE0 (msvcrt.dll) in ScriptCommunicator.exe: 0xC0000005: Access violation reading location 0x00000146F9046000.
Unhandled exception at 0x00007FF897F83DE5 (msvcrt.dll) in ScriptCommunicator.exe: 0xC0000005: Access violation reading location 0x000001B3EB64B000.
Unhandled exception at 0x00007FF897F83DE5 (msvcrt.dll) in ScriptCommunicator.exe: 0xC0000005: Access violation reading location 0x000001B3EB64B000.

From callstack in VisualStudio after crash I can see mostly QT dlls but they also vary from crash to crash, it looks like some time hazard or access to port?

What would you need to get more from me to somehow try to solve it? Creating small snippet can be hard to help because SC needs communication with external board to reproduce issue.

Here is small fragment where communication is done:

function at_send_cmd(cmd)
{   
    /* Send command */
    at_comport_handle.writeString(payload);
    status = at_comport_handle.waitForBytesWritten(50); //around 20 bytes with baud 115200

    if(status == false)
    {
        print("TX failed: " + at_comport_handle.errorString());
        at_comport_handle.close();
        scriptThread.sleepFromScript(10);
        at_comport_handle.open();
        at_comport_handle.writeString(payload);
        status = at_comport_handle.waitForBytesWritten(50);
        print("After reopening port and another try: " + status + "\tError: " + at_comport_handle.errorString());
    }


    /* Try to get response */
    while(tries--)
    {
        while((subtries-- > 0) && !at_comport_handle.canReadLine())
        {
            error = at_comport_handle.errorString()
            if(error != "Unknown error")
            {
                print("RX error: " + error);                            
            }

            scriptThread.sleepFromScript(50)
        }

        response = at_comport_handle.readAllLines()
}

at_comport_handle is just handle to serialPort class object.

Best regards,
Adam

[Stefan Zieker]

Hi Adam,

I did run a serial port test script and everything worked fine. ScriptCommunicator just routes the QSerialPort functions. I think it must be a combination of your calls that crashes in the new version (Qt 6.4 instead of Qt 5.14). Can you send me your scipt so that I can maybe reproduce it?

Regards,
Stefan

[Stefan Zieker]

Can you run your script with the test version of ScriptCommunicator in the attachment please?

[Anonymous]

Hi Stefan,

thanks for fast response! I haven't expected to have any answer before weekend :D
About your test version, unfortunately it also fails but after longer time and looks like there are more communication errors.

I will try to shrink scipt to minimum just to reproduce issue and upload it here, but most probably after weekend.

Best regards and thanks again for your support :)
Adam

[Anonymous]

Hi Stefan,

finally I had time to prepare snippet (attached in zip file).

Main js file is DEVBOX.js

After running script there is dropdown menu when you select COM port.
In original script there is few more dropdown lists with com ports for other functionalities, that's why I don't use "main" communication port.

I've also snip UI and functionality and reduce communication to only one command which is send constantly: "AT+CIO".
So there is should be only following request-response:

REQ: "AT+CIO?aa0f\r"
RSP: "\r\n0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\r\n\r\nOK\r\n33F0\r\n"

I've check if snippet version will also fail and yes, it can happen after 5s, after 10s or 2 minutes.

Unfortunately your version doesn't see any bytes received so it looks like not working correctly, but it also fails (after longer time).

Problematic function "at_send_cmd" sits in at_commands.js, the issue probably happens around lines 142 and 170.

If you could confirm that it also fails on your side it would be great (at least as entry point to solve it).

Best regards,
Adam

[Stefan Zieker]

Hi Adam,

thx for your script. I will test it on thursday (I'm on vacation at the moment(Berlin)).
Regards,
Stefan

[Stefan Zieker]

Hi Adam,

I executed your script and connected it via a virtual serial port to a second instance of ScriptCommunicator (to see what is sent). I can see that your script sends AT+CIO?*aa0f\r every second. But ScriptCommunicator does not crash. Must I sent something to the script to provoke a crash?

Regards,
Stefan

[Anonymous]

Hi Stefan,

maybe the issue sits in receiving data? For such request target board responses with r\n0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\r\n\r\nOK\r\n33F0\r\n

You can also check in SC console it response data is received or not. Maybe there is some issue between QT6 and com port drivers? On target board there is FTDI chip which uses its "standard" drivers.

In my case it was crashing in random moment after maximum 30s.
Anyway I'm glad that you investiate it, thanks!

Best regards,
Adam

[Anonymous]

Hi Adam,

I'm not sure if I understand you. Does the script crash if it is just executed (and sends cyclically) or shall I send the data from your last post to the script?

I have some FTDI cables at work. I can test the script with them next Monday.

Regards,
Stefan

[Anonymous]

Hi Stefan,

second option is the right one, script has to maintain communication in both sides. It sends cyclically request ("AT+CIO") and checks if response is ready, therefore other side has to have small "logic", at least something like if(serial.read() == 'AT+CIO') {tx.write('\r\n0,0,0,0\r\n');}

Best regards,
Adam

[Anonymous]

Hi Adam,

can you test the attached version of ScriptCommunicator? I switched from Qt 6.4.2 to QT 6.4.3 and the test script does not crash anymore (maybe it is this bug: QTBUG-108450 REG: Qt 6.3.2 WinOverlappedNotifier possible crash).

PS: You should not call bringWindowsToFrontSlot (line 1408). This is an internal function (even it can be called from script). Where did you find that function in the documentation?
The reason is that functions of GUI elements must only be called in the main thread. In ScriptCommunicator every script is executed in its own thread. If you call functions of a script GUI element events are generated internally. These events are connected to slot functions in the main thread.
And by the way if ScriptCommunicator creates a Dialog or a MainWindow it calls bringWindowsToFrontSlot of this object and therefore there is no need to call this function from script.

Regards,
Stefan

[Stefan Zieker]

Hi Adam,

I have already created a new release of ScriptCommunicator (6.06). This version uses Qt6.4.3 instead of Qt6.4.2.

Regards
Stefan

[Michael White]

I have just installed 6.06. When I click on Help->About, it says Version 6.0.5 but does show qt version 6.4.3. I can only guess this really is version 6.0.6 as it is the correct version of qt and it was the application version string was not updated. If this is not really version 6.0.6, please let me know what else I need to do as I have downloaded and installed it twice with the same results.

[Stefan Zieker]

Hi,

you are right. It is version 06.06. I only forgot to increase the version number. I fixed it and uploaded a new release for windows.
Thx for reporting this.