Bug #2575
closedOsmocomBB "mobile" program aborts with recent libosmocore
100%
Description
As described by a user on IRC:
15:42 < ntd> osmocom mobile crashes on start: https://pastebin.mozilla.org/9069998 15:44 < ntd> i've read that a similar error was caused my a mismatch between the system-installed libosmocore and the one bundled with osmocom-bb 15:45 < ntd> so i've tried just installing the libosmocore bundled with bb (to no avail) as well as try to compile osmocom-bb with master libosmore inside src/shared 15:45 < ntd> no joy, same error, different addresses 15:55 < tnt> .... 15:55 < tnt> http://git.osmocom.org/osmocom-bb/tree/src/README.building 15:55 < tnt> """DO NOT USE the libosmocore version embedded in this git tree. This s a special version used internally and MUST NOT be used as system-wide libosmocore.""" 15:56 < tnt> how much clearer can we be ... 15:56 < ntd> yeah, this was generally a last-ditch hail mary 15:56 < ntd> no damage done. osmocom-bb master mobile still doesn't work when compiled against libosmocore master 15:57 < tnt> There has been a lot of potentially breaking changes in libosmovty lately. My guess is that osmocom-bb just doesn't work with the latest one. 15:57 < ntd> commit suggestion? 15:58 < tnt> not really no. 15:58 < tnt> But whatever latest libosmocom commit was on the date of the last commit on the osmocom-bb branch of interest most likely works. 15:59 < tnt> *libosmocore 15:59 < ntd> ok. for some reason this issue affects me across master, laforge/testing, laforge/burst_ind etc. the only one working is sylvain/burst_ind 16:00 < ntd> i'll try backtracking libosmo to bb master date, thanks 16:04 < ntd> waddayaknow, the sep 7 osmocore commit worked. did spot a lot of changes to vty in the log, thanks :)
Please see the following excerpt from the related pastebin:
Assert failed !check_element_exists(cnode, cmd->string) command.c:719 backtrace() returned 7 addresses /usr/local/lib/libosmovty.so.3(install_element+0xc9) [0x7f149dadb969] ./mobile(+0x4eae6) [0x560859aa3ae6] ./mobile(+0x167ef) [0x560859a6b7ef] ./mobile(+0x15cbd) [0x560859a6acbd] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f149d3032e1] ./mobile(+0x15dba) [0x560859a6adba] Aborted
I could reproduce the problem locally. It seems to be related to the "ournode_exit_cmd" registrations at various nodes.
Files
Updated by laforge over 6 years ago
I suspect the culprit will be f4f23bd6829f78741cfd586f0ca9a290f221242e
or any of the related commits.
I'm wondering what was the intended backward/forward compatibility of this change?
Sure, we can remove the ournode_{exit,end}_cmd from the 'mobile' program. But then, what if you build that same source against older libosmovty? We'd probably have to make sure only new libosmovty versions are permitted during the ./configure phase.
We have to get more careful about breaking applications, and particularly forward compatibility of old applications with new libosmocore.
Updated by laforge over 6 years ago
- File 0001-WIP-untested-remove-ournode_-exit-end-_cmd.patch 0001-WIP-untested-remove-ournode_-exit-end-_cmd.patch added
attached an (incomplete!) patch that at least doesn't crash "mobile" at startup anymore
Updated by neels over 6 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
hmm, I should have seen this ticket a week ago. It's the first time I notice.
It should be fixed by Vadim's patch https://gerrit.osmocom.org/#/c/4373/.
This issue could have gone smoother from my side, apologies.