mb2hal test: switch test interface to tcp

[hansu]

See #2274 (comment)

[SebKuzminsky]

Hi @hansu , thanks for working on this.

I don't think this debug level tweak will work for the mb2hal.1b test, since it parses halcmd show output. I suggest instead running the result (and expected) files through sed to remove all mention of specific component IDs. I'll push a branch in a few minutes to show what I mean.

[hansu]

Oh yes you are right. I thought only the id in mb2hal's debug log is the problematic one. But that id is also shown in hacmd show :/.

[hansu]

Reacting to #2456 (comment), I changed the interface for the test configuration to tcp instead of tty as the test host does not seem to have a tty.

[SebKuzminsky]

The two options for libmodbus are TCP and RTU (which is serial). Though the lack of a serial modbus device to talk to causes lots of errors to be printed, I don't think that's the cause of the test failures. See #2458.

[SebKuzminsky]

I still get segfaults with this branch, after just a few seconds of running this on Stretch with a vanilla kernel:

$ while runtests -n ../tests/mb2hal/; do true; done

Here's a typical backtrace:

(gdb) thread apply all bt

Thread 2 (Thread 0x7f25de9ba740 (LWP 30005)):
#0  0x00007f25dd9bb6d7 in shmctl () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f25de5ba0c0 in rtapi_shmem_delete (handle=1, module_id=<optimized out>)
    at ./rtapi/uspace_common.h:184
#2  0x00007f25de5b6ce1 in hal_exit (comp_id=4) at hal/hal_lib.c:354
#3  0x00005557449a9779 in quit_cleanup () at hal/user_comps/mb2hal/mb2hal.c:453
#4  0x00005557449a8a82 in main (argc=<optimized out>, argv=<optimized out>)
    at hal/user_comps/mb2hal/mb2hal.c:109

Thread 1 (Thread 0x7f25dcbb8700 (LWP 30006)):
#0  0x00007f25ddc72f50 in modbus_set_socket () from /usr/lib/x86_64-linux-gnu/libmodbus.so.5
#1  0x00005557449a8d57 in get_tx_connection (this_mb_tx_num=0, ret_connected=0x7f25dcbb7edc)
    at hal/user_comps/mb2hal/mb2hal.c:342
#2  0x00005557449a92c7 in link_loop_and_logic (thrd_link_num=<optimized out>)
    at hal/user_comps/mb2hal/mb2hal.c:172
#3  0x00007f25de1954a4 in start_thread (arg=0x7f25dcbb8700) at pthread_create.c:456
#4  0x00007f25dd9b9d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
(gdb) 

This is the shutdown race condition that #2458 addresses.

Note that thread 2 is in quit_cleanup(), and it has called hal_exit(). That means it's past the part of quit_cleanup() where it calls modbus_close() and modbus_free() on all the gbl.mb_links[].modbus contexts and sets them all to NULL.

Meanwhile, thread 1 is running get_tx_connection() and trying to access the modbus context, folloing the NULL pointer, and segfaulting.

[hansu]

Though the lack of a serial modbus device to talk to causes lots of errors to be printed, I don't think that's the cause of the test failures.

But isn't the change worth reducing those error prints?

[SebKuzminsky]

Hmm, maybe... Do you know if it actually tries to send any TCP packets? It would probably not be a good idea to have the tests sending packets to whatever nearby machine has that IP address.

Maybe you could set the target address to the localhost (127.0.0.1), and maybe you could even have a mock modbus device listening there.

[hansu]

Hmm, maybe... Do you know if it actually tries to send any TCP packets?

Yes I would say so.

It would probably not be a good idea to have the tests sending packets to whatever nearby machine has that IP address.

Yes maybe

Maybe you could set the target address to the localhost (127.0.0.1), and maybe you could even have a mock modbus device listening there.

Would be a nice complete test, but maybe a bit overdone considering this is only one of many components...