gsmd locks-up if libgsmd-tool disconnects too quickly

[pavel@…]

echo "sl=1,100" | libgsmd-tool -m shell

...confuses gsmd, so that nothing more works.

[tick@…]

In fact libgsmd-tool work well here. The command "sl" is asynchronous. The
real result will return in a form of notification. Therefore, when the command
get an "OK" response it is done. And libgsmd-tool will then be terminated.
It's normal you cannot see the notification, because in the respect of this
command, it is done already.

[pavel@…]

well, I was not complaining about not getting response, I was complaining about
gsmd getting totally confused after commandline above, and refusing to do
anything more.

[tick@…]

Would you please post the log of how you confuse gsmd?
(better contains both gsmd and libgsmd-tool message )
Thanks

[balrogg@…]

I'm seeing this too, so reopening. If a libgsm client disconnects too quickly,
gsmd gets confused, and locks-up, gdb showed this backtrace (it was echo n | ...
in my case):

#0 usock_cmd_enqueue (ucmd=0x308d0, gu=0x308d0)

at ../../include/common/linux_list.h:73

#1 0x0000e07c in network_ownnumbers_cb (cmd=0x30800, ctx=0x308d0,

resp=0x20060 "+CNUM: ,\"507328011\",129") at usock.c:597

#2 0x0000b2ac in atcmd_done (g=0x1db4c, cmd=0x30800, buf=0x1e3bc "OK")

at atcmd.c:268

#3 0x0000bf58 in atcmd_newdata_cb (opaque=<value optimized out>,

data=0x1f0ef "\r\n29_{,0\r\n6A3D100\r\nA3D168341A8D46",
len=<value optimized out>) at atcmd.c:174}

#4 0x0001362c in uart_select_cb (fd=3, what=1, data=<value optimized out>)

at uart.c:115

#5 0x0000c1f8 in gsmd_select_main () at select.c:98
#6 0x0000ad98 in main (argc=<value optimized out>, argv=<value optimized out>)

at gsmd.c:463

I will have a look at it later and try to send a patch.

[balrogg@…]

Primitive patch to fix gsmd client disconnection

[balrogg@…]

Add libgsmd-tool -m shell -w switch.

[balrogg@…]

err, #59

[tick@…]

I'd like to switch this bug since we have sleep mode.

[balrogg@…]

Sorry, but what does the sleep command have to do with this bug? Imho it's
completely irrelevant. Basically, you made a change in libgsmd-tool and you're
saying that a bug that's in gsmd (not libgsmd-tool) is now fixed. How can it
possibly be fixed? This *is* a gsmd bug, not a libgsmd-tool bug.

Apart from that, S= command is flawed, you can't predict how long a command will
take and it definitely shouldn't be used in scripts. It's a hack and, even if
it may be useful for developers to test, the -w switch should be used instead.

Also please learn to use the "Resolution: FIXED" and "Resolution: WONTFIX"
bugzilla options. In some bugs you say that they will not be fixed and then you
mark it as "FIXED", it's illogical.

I can't understand why when you have a proper fix at hand, submitted on
bugzilla, you insist on wasting your time rewriting the code (and introducing
new bugs, changing function names to illogical ones, and replacing tabs by
spaces everywhere). If you see an error in some of the submitted patches, point
it out, discuss, and ask the submitter to resubmit. Ignoring is extremely rude
and it is currently destroying the gsmd project. The code quality has dropped
very badly since laf0rge left it and now the gsmd code looks like a "hello
world" made by a first-time C learner.

[tick@…]

We won't fix this bug now, but since we have wait and sleep mode this can be
avoided in libgsmd-tool.

Notice: libgsmd shall not be connect and disconnect too rapidly to gsmd.

[balrogg@…]

I'm wondering if you can still see the bug? Is the backtrace output still the
same? For me the recent change fixed it and libgsmd can now disconnect as
quickly as it likes and gsmd doesn't seem to break.

[balrogg@…]

Reopening to mark FIXED since the bug is now fixed and there's been no more reports.

[balrogg@…]

Marking as Resolved: FIXED.