Bug #2575

OsmocomBB "mobile" program aborts with recent libosmocore

Added by laforge about 1 year ago. Updated 9 months ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


As described by a user on IRC:

15:42 < ntd> osmocom mobile crashes on start:
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>
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/ [0x7f149dadb969]
./mobile(+0x4eae6) [0x560859aa3ae6]
./mobile(+0x167ef) [0x560859a6b7ef]
./mobile(+0x15cbd) [0x560859a6acbd]
/lib/x86_64-linux-gnu/ [0x7f149d3032e1]
./mobile(+0x15dba) [0x560859a6adba]

I could reproduce the problem locally. It seems to be related to the "ournode_exit_cmd" registrations at various nodes.


#1 Updated by laforge about 1 year 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.

#2 Updated by laforge about 1 year ago

attached an (incomplete!) patch that at least doesn't crash "mobile" at startup anymore

#3 Updated by neels 12 months 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
This issue could have gone smoother from my side, apologies.

#4 Updated by laforge 9 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)