ChipLoad crashes on Linux due to assert

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi,

     WICED SDK 2.2.0, Ubuntu 14.04 64bit, BCM20736 based custom board.  The ChipLoad utility permanently crashing when I do either download or recover procedure. Here is the log:

ChipLoad: ../nptl/pthread_mutex_lock.c:80: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.

   The same procedure with Broadcom dev kit works fine.

0 Likes
1 Solution
Anonymous
Not applicable

Hi @kwang

    ericmoon-ubnt is right. Both 32bit and 64bit Linux binaries of ChipLoad tool are binary equal between 2.2.0 and 2.2.1 SDKs. This tool does not dynamically link any other SDK libraries which could affect the behaviour, so there is simply no chance that new SDK 2.2.1 fixes the crash of ChipLoad tool.

    It is the same tool basically. No changes were made at all.

BR, Andrey

View solution in original post

0 Likes
15 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

Can you provide the traces from chipload.

Also, can you program your custom board using the SDK/Windows ?

I'm not sure how much testing has been done with Chipload on Linux.

0 Likes
Anonymous
Not applicable

Yes, SDK on Windows works fine, and also it works fine on 32-bit Linux and on other version of 64-bit Linux. So it looks to be a subtle timing issue with ChipLoad. There is nothing more in the log, just these two lines:

ChipLoad: ../nptl/pthread_mutex_lock.c:80: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.

Aborted (core dumped)

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

I also managed to get a core dump (attached). Backtrace is the following:

Core was generated by `Tools/ChipLoad/Linux32/ChipLoad -BLUETOOLMODE -PORT /dev/ttyUSB0 -BAUDRATE 1152'.

Program terminated with signal SIGABRT, Aborted.

#0  0x55577430 in __kernel_vsyscall ()

(gdb) bt

#0  0x55577430 in __kernel_vsyscall ()

#1  0x55733607 in raise () from /lib/i386-linux-gnu/libc.so.6

#2  0x55736a33 in abort () from /lib/i386-linux-gnu/libc.so.6

#3  0x5572c757 in ?? () from /lib/i386-linux-gnu/libc.so.6

#4  0x5572c807 in __assert_fail () from /lib/i386-linux-gnu/libc.so.6

#5  0x555a513f in pthread_mutex_lock () from /lib/i386-linux-gnu/libpthread.so.0

#6  0x080553b4 in ?? ()

#7  0x08056976 in ?? ()

#8  0x080555c0 in ?? ()

#9  0x555a2f70 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0

#10 0x557f150e in clone () from /lib/i386-linux-gnu/libc.so.6

The full command for ChipLoad invocation was the following:

Tools/ChipLoad/Linux32/ChipLoad -BLUETOOLMODE -PORT /dev/ttyUSB0 -BAUDRATE 115200 -MINIDRIVER Platforms/BCM920736TAG_Q32/uart_DISABLE_EEPROM_WP_PIN1.hex -BTP Platforms/BCM920736TAG_Q32/20736_EEPROM.btp -CONFIG build/hello_sensor-BCM920736TAG_Q32-rom-ram-Wiced-release/hello_sensor-BCM920736TAG_Q32-rom-ram-Wiced-release.hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251

0 Likes

How often can you reproduce this ?  why do you feel its timing related issue ? Is this issue seen only using your custom board and not our dev kit board ? If you could share details related to your custom board as a private message we could look to see if there is something different in the design that's causing the download failure.

thnx

vik86

PS: You have answered to a couple questions I've asked. Just want to confirm once again.

0 Likes
Anonymous
Not applicable

How often can you reproduce this ?  ---> Always with our board.

why do you feel its timing related issue ?  ---> Because of mutexes Well, it just a guess, don't take it seriously.

Is this issue seen only using your custom board and not our dev kit board ? ---> yes

Not sure what details you need about our board. AFAIK, debug UART port connection scheme on our board is the same as on dev board (I'm a SW guy). Anyway, you have the backtrace and core dump. It should give a lot of info for the developers. They can create a custom binary with fixes or additional debug traces and give me for a try.

0 Likes

thnx for your responses, working with developers to help you solve this issue.

thnx

vik86

0 Likes

As per previous conversation , our test engineers did not see any issue on the 64 bit Linux machine using our Tag03. Since you are having an issue to switch back and forth from 32 to 64 bit. Would suggest you to re install the SDK and try compiling the application on your 64 bit machine.. Let us know if you resolve it.

0 Likes
Anonymous
Not applicable

Hi,

  I tried it again with my existing SDK and now it sometimes crashes, sometimes not! So it definitely is a timing issue (race condition) in your ChipLoad application.

   I suggest your developers to try Ubuntu 64bit 14.01.01

0 Likes

andrejs.hanins@ubnt.com

Is this still an open issue?

0 Likes
Anonymous
Not applicable

Why you ask me?

You should fix it, not me.

0 Likes

You are correct.  I was confused.

We are waiting for next release of the WICED Smart SDK to verify the Linux installer for x32/x64.

0 Likes
Anonymous
Not applicable

Hi andrejs.hanins@ubnt.com,

Just wanted to let you know SDK 2.2.1 for Linux has been released.  WICED-Smart-SDK-2.2.1-IDE-Installer.bin (Linux)

Hope this solves the problem!

-Kevin

0 Likes
Anonymous
Not applicable

The Linux64 CGS and ChipLoad binaries in 2.2.1 appear to be identical to the 2.2.0 versions.

0 Likes
Anonymous
Not applicable

Hi @kwang

    ericmoon-ubnt is right. Both 32bit and 64bit Linux binaries of ChipLoad tool are binary equal between 2.2.0 and 2.2.1 SDKs. This tool does not dynamically link any other SDK libraries which could affect the behaviour, so there is simply no chance that new SDK 2.2.1 fixes the crash of ChipLoad tool.

    It is the same tool basically. No changes were made at all.

BR, Andrey

0 Likes
Anonymous
Not applicable

Hi andrejs.hanins@ubnt.com,

Sorry, that was my mistake, we have people looking into this issue.

-Kevin

0 Likes