Skip to content

Bug: Crash when slave invalid address is added #9

@ramonhpr

Description

@ramonhpr
$ sudo valgrind --leak-check=full src/modbusd 
==1033== Memcheck, a memory error detector
==1033== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==1033== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==1033== Command: src/modbusd
==1033== 
Starting manager ...
Starting dbus ...
Name acquire complete.
Starting slave ...
Starting source ...
slave_ref(0x5875d50): 1
Slave(0x5875d50): (/slave_3b8d616040201ed5) url: (tcp://yahoo.com:80)
slave_ref(0x5875d50): 2
slave_ref(0x58779c0): 1
Slave(0x58779c0): (/slave_5f8cb08ed47472eb) url: (tcp://google.com:80)
slave_ref(0x58779c0): 2
slave_ref(0x5879630): 1
Slave(0x5879630): (/slave_979174b28eae2fe3) url: (tcp://google.com)
slave_ref(0x5879630): 2
RTU: tcp://yahoo.com:80
RTU: tcp://google.com:80
Address (tcp://google.com) not supported: Invalid format
==1033== Invalid read of size 8
==1033==    at 0x5293E40: modbus_set_slave (in /usr/lib/x86_64-linux-gnu/libmodbus.so.5.0.5)
==1033==    by 0x402ECC: enable_slave (slave.c:309)
==1033==    by 0x4E4BFF9: timeout_callback (timeout.c:81)
==1033==    by 0x4E4B659: l_main_iterate (main.c:473)
==1033==    by 0x4E4B72B: l_main_run (main.c:520)
==1033==    by 0x4E4B94A: l_main_run_with_signal (main.c:642)
==1033==    by 0x40270F: main (main.c:97)
==1033==  Address 0x30 is not stack'd, malloc'd or (recently) free'd
==1033== 
==1033== 
==1033== Process terminating with default action of signal 11 (SIGSEGV)
==1033==  Access not within mapped region at address 0x30
==1033==    at 0x5293E40: modbus_set_slave (in /usr/lib/x86_64-linux-gnu/libmodbus.so.5.0.5)
==1033==    by 0x402ECC: enable_slave (slave.c:309)
==1033==    by 0x4E4BFF9: timeout_callback (timeout.c:81)
==1033==    by 0x4E4B659: l_main_iterate (main.c:473)
==1033==    by 0x4E4B72B: l_main_run (main.c:520)
==1033==    by 0x4E4B94A: l_main_run_with_signal (main.c:642)
==1033==    by 0x40270F: main (main.c:97)
==1033==  If you believe this happened as a result of a stack
==1033==  overflow in your program's main thread (unlikely but
==1033==  possible), you can try to increase the size of the
==1033==  main thread stack using the --main-stacksize= flag.
==1033==  The main thread stack size used in this run was 8388608.
==1033== 
==1033== HEAP SUMMARY:
==1033==     in use at exit: 47,195 bytes in 275 blocks
==1033==   total heap usage: 1,037 allocs, 762 frees, 284,939 bytes allocated
==1033== 
==1033== LEAK SUMMARY:
==1033==    definitely lost: 0 bytes in 0 blocks
==1033==    indirectly lost: 0 bytes in 0 blocks
==1033==      possibly lost: 0 bytes in 0 blocks
==1033==    still reachable: 47,195 bytes in 275 blocks
==1033==         suppressed: 0 bytes in 0 blocks
==1033== Reachable blocks (those to which a pointer was found) are not shown.
==1033== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==1033== 
==1033== For counts of detected and suppressed errors, rerun with: -v
==1033== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions