Ticket #894 (closed defect: fixed)

Opened 11 years ago

Last modified 11 years ago

gsmd locks-up if libgsmd-tool disconnects too quickly

Reported by: pavel@… Owned by: tick@…
Priority: high Milestone:
Component: gsmd Version: unspecified
Severity: normal Keywords:
Cc: buglog@…, balrogg@…, mstevens@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: PatchReviewResult:
Reproducible:

Description

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

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

Attachments

0001-Make-sure-no-references-to-user-struct-are-left-befo.patch (2.3 KB) - added by balrogg@… 11 years ago.
Primitive patch to fix gsmd client disconnection
0002-Add-libgsmd-tool-m-shell-w-for-synchronous-executi.patch (9.5 KB) - added by balrogg@… 11 years ago.
Add libgsmd-tool -m shell -w switch.

Change History

comment:1 Changed 11 years ago by jserv@…

  • Owner changed from laforge@… to ticktock35@…

comment:2 Changed 11 years ago by tick@…

  • Status changed from new to closed
  • Resolution set to invalid

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.

comment:3 Changed 11 years ago by 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.

comment:4 Changed 11 years ago by tick@…

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

comment:5 Changed 11 years ago by balrogg@…

  • Cc balrogg@… added
  • Summary changed from gsmd crashes libgsmd-tool disconnects too quickly to gsmd locks-up if libgsmd-tool disconnects too quickly

comment:6 Changed 11 years ago by balrogg@…

  • Status changed from closed to reopened
  • Resolution invalid deleted

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.

comment:7 Changed 11 years ago by mstevens@…

  • Cc mstevens@… added

Changed 11 years ago by balrogg@…

Primitive patch to fix gsmd client disconnection

Changed 11 years ago by balrogg@…

Add libgsmd-tool -m shell -w switch.

comment:8 Changed 11 years ago by balrogg@…

err, #59

comment:9 Changed 11 years ago by tick@…

  • Status changed from reopened to closed
  • Resolution set to fixed

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

comment:10 Changed 11 years ago by balrogg@…

  • Status changed from closed to reopened
  • Resolution fixed deleted

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.

comment:11 Changed 11 years ago by tick@…

  • Status changed from reopened to assigned

comment:12 Changed 11 years ago by tick@…

  • Status changed from assigned to closed
  • Resolution set to wontfix

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.

comment:13 Changed 11 years ago by 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.

comment:14 Changed 11 years ago by balrogg@…

  • Status changed from closed to reopened
  • Resolution wontfix deleted

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

comment:15 Changed 11 years ago by balrogg@…

  • Status changed from reopened to closed
  • Resolution set to fixed

Marking as Resolved: FIXED.

Note: See TracTickets for help on using tickets.