raspberry pi : *** glibc detected *** ./ambitconsole: corrupted double-linked list: 0x002ce400 ***

[ang-st]

Hello, i try to run openambit on raspberry pi but it actually crashes

root@raspberrypi:/tmp/openambit/example-build# ./ambitconsole 
Device: Suunto Ambit3 Peak, serial: E50D0B510A000F00
F/W version: 1.0.46
Current charge: 90%
*** glibc detected *** ./ambitconsole: corrupted double-linked list: 0x00322080 ***
Aborted (core dumped)

i recompiled with -O0 and -ggdb flags and it appear to crash at some point while calling hid_read

 3964             hid_read [/tmp/openambit/libambit-build/libambit.so.0]  
 3964               hid_read_timeout [/tmp/openambit/libambit-build/libambit.so.0]  
 3964                 poll [/lib/arm-linux-gnueabihf/libc.so.6]  
 3964             usleep [/lib/arm-linux-gnueabihf/libc.so.6]  
*** glibc detected *** ./ambitconsole: corrupted double-linked list: 0x002ce400 ***

here is the backtrace generated by the coredump

root@raspberrypi:/tmp/openambit/example-build# gdb --quiet -c core ambitconsole 
Reading symbols from /tmp/openambit/example-build/ambitconsole...done.
[New LWP 3964]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `./ambitconsole'.
Program terminated with signal 6, Aborted.
#0  0xb6ccf8dc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
(gdb) bt
#0  0xb6ccf8dc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0xb6cd365c in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#2  0xb6f79d80 in ?? () from /lib/ld-linux-armhf.so.3
#3  0xb6900468 in ?? ()
Cannot access memory at address 0x0
#4  0xb6900468 in ?? ()
Cannot access memory at address 0x0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

I would be glad to help you to fix this issue, as i intend to use libambit on a kind of funny project. Thanks in advance

[paddy-hack]

Please note that Ambit3 support (#54) is still a work in progress.

I was not able to reproduce this with my Suunto Ambit on an amd64 Debian jessie machine with 921fce1. What version of the code are you using? Would you be able to test on amd64 or i386 so we can rule out architecture issues? Which of the hidapi implementations are you using? From the information above, I would guess the hid-libusb.c one. I've tried reproducing with both that implementation as well as the default hid-linux.c one.

[ang-st]

right it seems to be arch dependent, it run fine on x86, i only had the issue on arm.

I will investigate further in the next week as soon as i get the watch back. Thanks for pointing me that there are two implementations of hid available. I will try both. The problem occured on the latest version, I didn't try to go backward in revesion but I suspect it won't help. Thanks for your time

[ang-st]

Hello, i found where the bug was located, a simple missing parenthesis resulting a wrong memory allocation at libambit_sbem0102_command_request

the original code only alloc data_objects->size thu the subsequent memcpy write out of bound and corrupt the heap.

// file src/libambit/sbem0102.c:119
send_data = malloc(sizeof(special_header) + data_objects != NULL ? data_objects->size : 0);

this way it evaluate the ternary operator and then sum it to sizeof(special_header)

 send_data = malloc(sizeof(special_header) + (data_objects != NULL ? data_objects->size : 0));

then the code run fine :-) On a side note i don't know why this work on x86 and only occur in arm, while i don't think the extra parentethis will hurt on either platform.

[paddy-hack]

Thanks!

You missed two other malloc() statements in the same file that had the same problem but that's no problem. I'll be pushing a fix in a jiffy.

As to your side note, writing beyond allocated memory bounds results in undefined behaviour. The crashing you observed on arm is one kind of undefined behaviour, everything going fine on x86 is another kind of undefined behaviour :sweat_smile: