On 22 October 2017 at 19:20, Snehasish Kar snehasish.cse@live.com wrote:
Hello Vadim
I tried using your trxcon along with grgsmtrx, but when i start the app mobile in the l2l3 software it gives me the following error:
Assert failed !check_element_exists(cnode, cmd->string) command.c:627 backtrace() returned 7 addresses /usr/local/lib/libosmovty.so.3(install_element+0x136) [0x7f7a8c7fd4b6] ./mobile() [0x43d371] ./mobile() [0x40548e] ./mobile() [0x4049e7] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f7a8bffaf45] ./mobile() [0x404a83]
Please help.
Hi,
This message was forwarded to the ML. Please do the same in the future to make others able to know about the problem and possible solutions.
Actually, this crash isn't related to trxcon application anyhow, it's caused by the recent libosmocore changes, related to the VTY default nodes. A quick solution would be to drop all custom 'exit' commands from the 'vty_interface.c'.
I'll try to fix the problem in spare time... If you have some time and feel yourself able to write a proper fix, just send me a patch, and I'll review one ASAP ;)
BTW: we have some updates regarding to TX support. Please look at the 'origin/ptrkrysik/trx' and 'axilirator/fixeria/trx' on GitHub.
With best regards, Vadim Yanitskiy.
On Sun, Oct 22, 2017 at 07:33:10PM +0330, Vadim Yanitskiy wrote:
I tried using your trxcon along with grgsmtrx, but when i start the app mobile in the l2l3 software it gives me the following error:
Assert failed !check_element_exists(cnode, cmd->string) command.c:627 backtrace() returned 7 addresses /usr/local/lib/libosmovty.so.3(install_element+0x136) [0x7f7a8c7fd4b6] ./mobile() [0x43d371] ./mobile() [0x40548e] ./mobile() [0x4049e7] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f7a8bffaf45] ./mobile() [0x404a83]
Please help.
Actually, this crash isn't related to trxcon application anyhow, it's caused by the recent libosmocore changes, related to the VTY default nodes. A quick solution would be to drop all custom 'exit' commands from the 'vty_interface.c'.
Then it should be my fault. Can I do anything to help fix it?
Can you explain why custom 'exit' commands need to be dropped? That shouldn't be the case for a telnet VTY, only while reading in VTY config from a file.
~N
Hi Neels,
Can you explain why custom 'exit' commands need to be dropped? That shouldn't be the case for a telnet VTY, only while reading in VTY config from a file.
I think, this happens due to the following change:
22bc45b8bfb8d0f2d8a46c6e945f3b4388fdced0
since which every application does install default commands by default, including 'exit' and 'end'.
At the moment there are the custom 'exit' and 'end' commands in the OsmocomBB/mobile/vty_interface.c. So, the crash happens because it attempts to install already existing commands.
Then it should be my fault. Can I do anything to help fix it?
I've prepared a fix for that, have a look please:
https://gerrit.osmocom.org/4373
Also, I've fixed one more thing by the way:
https://gerrit.osmocom.org/4374
With best regards, Vadim Yanitskiy.
On Mon, Oct 23, 2017 at 12:42:25AM +0330, Vadim Yanitskiy wrote:
At the moment there are the custom 'exit' and 'end' commands in the OsmocomBB/mobile/vty_interface.c. So, the crash happens because it attempts to install already existing commands.
Ah, damn. I checked all of the repositories I know to use the VTY, I didn't imagine that OsmocomBB also has a VTY. That's really my fault then.
Lucky for me that the BB custom ones seem to merely dup the libosmocore stock ones, so I get away with your patch:
Also, I've fixed one more thing by the way: https://gerrit.osmocom.org/4374
well done.
Thanks for saving my A
~N
Hi guys,
I have this in the gerrit/laforge/ournode-vty since October 14, and thre was some discussion either on the ML or on redmine about it, otherwise I wouldn't have written it at the time, while on holidays.
Regards, Harald On Mon, Oct 23, 2017 at 03:54:40AM +0200, Neels Hofmeyr wrote:
On Mon, Oct 23, 2017 at 12:42:25AM +0330, Vadim Yanitskiy wrote:
At the moment there are the custom 'exit' and 'end' commands in the OsmocomBB/mobile/vty_interface.c. So, the crash happens because it attempts to install already existing commands.
Ah, damn. I checked all of the repositories I know to use the VTY, I didn't imagine that OsmocomBB also has a VTY. That's really my fault then.
Lucky for me that the BB custom ones seem to merely dup the libosmocore stock ones, so I get away with your patch:
Also, I've fixed one more thing by the way: https://gerrit.osmocom.org/4374
well done.
Thanks for saving my A
~N
Hi Neels,
On Mon, Oct 23, 2017 at 03:54:40AM +0200, Neels Hofmeyr wrote:
Ah, damn. I checked all of the repositories I know to use the VTY, I didn't imagine that OsmocomBB also has a VTY. That's really my fault then.
I think in general we should not fall into that trap. We have *no clue* at all who might be using libosmo* for whatever purpose. If we provide a libary with a given API/ABI, then it's our responsibility to keep that ABI/API as stable as possible.
I understand that it was hardly possible without fall-out in that particular case, and for sure there are exceptions.
However, completely unrelated to this particular topic (and hence the Cc to openbsc@) I'm not happy in general with the way how "carlessly" we sometimes introduce breakage. We have to be more disciplined in general on this. All of us.
BTW: The fact that this change has gone into master without being noticed also means that possibly we're not modelling osmocom-bb as a downstream user of libosmocore that needs to be rebuilt (and at least checked if it starts up correctly?) whenever testing a libosmocore change. That's also something to investigate. Maybe there's some way we can test this without too much effort.
Regards, Harald
On Mon, Oct 23, 2017 at 12:43:52PM +0200, Harald Welte wrote:
I think in general we should not fall into that trap. We have *no clue* at all who might be using libosmo* for whatever purpose. If we provide a libary with a given API/ABI, then it's our responsibility to keep that ABI/API as stable as possible.
True.
There are ways to fix this one: we can allow to register a given command a second time, which then replaces the previously registered command. We can also allow this only for the common node commands.
Should I implement this? Then upon new release, all potential VTY users out there can still register their own common node commands to replace the default ones and should not experience breakage.
~N
baseband-devel@lists.osmocom.org
-
Harald Welte -
Neels Hofmeyr -
Vadim Yanitskiy