Serial port crashes

steve64

I'm observing total crashes when using the serial module.
It's difficult to give you a full example since I got the problem when interacting with a special device,
sending commands and getting outputs over a USB UART.
It happens always in my test case but in slightly different random instants of same sequence.
Typically, I'm repeating similar command sequences in a loop, everything seems fine up to 3 or more iterations.
Using the step debugger I have found that is sometimes crashing inside the wait() call applied to a task for the serial port
obtained from write() or readline()
A typical sequence I'm using is like this:

local task = COM_PORT:write('erl 0 0 0 '..addr_low..'\n')
local sts = task:wait()  --> MAY CRASH HERE
print('read A', sts)
COM_PORT:flush()
task =  COM_PORT:readline('->')
sts = task:wait()  --> MAY CRASH HERE

Another hint: running the same app as exe instead that from LuaRT Studio, the crashes are a bit less frequent but still happen.

Samir

I don't have such device to test this
Did you try with standard serial port ?

steve64

I will try to find another device to cross-check.
Anyway, I was successful to talk with this device with other two solutions:
1) LuaRT 1.9.5 and an external DLL, through the "C" module API
2) Python serial API
So the device is not expected to be the root cause.
I suspect something in the task-based event-driven handling which is nicer but more complex.
Or something related to comm. timeouts in Win32. Are you using defaults?
Another possibility (while not so likely) is some kind of unexpected GC, closing the port in the middle of processing.

Samir

I will check this thank you for your précise report !

steve64

I tried collectgarbage('stop') at the beginning of my app.
This seems to avoid the serial port crashes...
Now the point is where the GC corrupts the serial port code.

Samir

Your bug report was correct, a crash occur in the Task when trying to free a buffer.
It'will be fixed in LuaRT 2.0.1

steve64

Using the new 2.0.1 I'm still facing the following issue with the serial module.
The following function to read a char crashes:

function read_char()
  local t = COM_PORT:read(1)
  print(t)
  local reply = t:wait() --> CRASH HERE!!!
  return reply:encode()
end

The COM_PORT is opened and the task is created, both are valid objects:

COM_PORT -> Port: 00000277E58E8790
t -> Task: 00000277E8D2D650

Let me add the that the read_char function is called inside a push button click callback.
The wait() method seems the crash point. I also tried an alternative with waitall() and also that crashes.
From investigation, it seems that the wait() never terminates and the task remains in "sleeping" status.

Samir

Damn....thank you Steve I will check it

steve64

It seems I'm now able to use the serial port, at least just relying on write() to send commands and readline() to get echo and data back. I think the issue was due to the following:
1) understand well the fact that readline() returns a buffer (reported as 'table') and that such buffer must be manipulated carefully (indexing, encoding, ...)
2) the device was responding with multiple different use cases and it was initially difficult to track all of them
Now, at least in my current scenario, I think I can go on with LuaRT 2.0.1 behavior.

Samir

Yes as all LuaRT binary data (socket:read(), File:read()...), the Port:read() and Port:readline() methods returns a Buffer value, that can be converted to a string with the wanted encoding

steve64

I have now found cases (not systematic, you need more trials at different speeds) where the following call:

reply = COM_PORT:readline('->'):wait()

returns a 'function' value and if not trapped it crashes my program.
Any idea why?

Samir

No idea, I will need to reproduce this issue

steve64

Sometimes also COM_PORT:write() returns a 'table' and the program usually craches in that cases

steve64

COM_PORT:write(cmd):wait() may also have problems sometimes
any interference with garbage collection, since there is a randomness in the crash points?

Samir

Maybe, I need to investigate

steve64

Some possible causes:

1) still issues with buffer allocation/deallocation on the C side of serial module
2) interference with the task (coroutines) scheduling, since I tried to disable GC and I still got the crashes

Crashes happen quite often but every time in random points of the code, while just after a write(), read() or readline() call.
It is like the Buffer object obtained by a serial port call vanishes later at some random point of time.

Look also at this example, in this pattern the read() ALWAYS crashes:

  repeat
    t = COM_PORT:read(1)
    print('--- after read ---', t, t.status)
    local buf = t:wait() --> ALWAYS CRASH HERE !!
  until not buf

Samir

I think I have resolved it.
The problem was due to a memory free that crashed because the Buffer object still used it.

Your assumptions were right ! Thank you again !

steve64

Thanks, are you going to deliver the fix soon as release update? If not, could you release at least the serial library module in advance? I have a critical project needing that fix on next week…

Samir

I can give you a download link to test it if you want :
[Login to see the link]

Just unpack both files in the modules\serial folder of your root LuaRT installation directory

Hope this version will fix the module

steve64

Many thanks, but unfortunately the new DLLs still show the same crash ...