Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000265TunixFreeEMS Pluginpublic2011-09-22 23:202012-03-30 20:37
ReporterFred 
Assigned Todandruczyk 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformLinuxOSDebianOS VersionSid/Unstable
Product Version0.9.24-SNAPSHOT 
Target Version0.9.24Fixed in Version0.9.24 
Summary0000265: Unplug Of USB Device Causes 100% CPU, Then Crash
Description[11:32] <Cheetah> djandruczyk_home: djandruczyk i just unplugged the serial port and mtx went 100% cpu
[11:33] <Cheetah> then i clicked close on the annoying dialog a few times before sneaking into a menu and choosing quit really quickly and got this:
[11:34] <Cheetah> http://pastebin.com/Hx1aQ6TH [^]
[11:34] <diyefi-bot> (gdb) backtrace #0 0xb6fdb3cc in free () from /lib/i386-linux-gnu/i686/cmov/li - Pastebin.com
[11:34] <Tarzan> [Link Info] title: (gdb) backtrace #0 0xb6fdb3cc in free () from /lib/i386-linux-gnu/i686/cmov/li - Pastebin.com
[11:36] <Cheetah> context: talking to freeems when i pulled the plug
TagsNo tags attached.
FirmwareVersionunknown, updating issue to appear in roadmap
Attached Files

- Relationships

-  Notes
(0000290)
dandruczyk (viewer)
2011-09-26 00:34

Doesn't crash for me. It does exactly what it's supposed to do, it begins re-scanning serial ports to see if it can re-connect to the device. I don't get a crash, and when i reconnect in between 1-5 seconds (depending on where in hte list of potential ports it's currently on) it restores normal behavior. I don't jsut bang on the original port opened since usb->serial port names are dynamic and a quick unplug/replug is NOT guaranteed to get the same name or comm port number in the case of Winblows chunks.
User avatar (0000299)
Fred (administrator)
2011-09-26 01:38

Additional info: Only happens in FreeEMS mode, not JimStim mode. Two instances, pulled plug on hub with both attached. FreeEMS instance had the CPU usage. Ctrl C = don't know if it would have died or not.
(0000300)
dandruczyk (viewer)
2011-09-26 02:16

I teated it in freeems mode u should retry....
User avatar (0000309)
Fred (administrator)
2011-09-26 16:24

Crash doesn't seem to happen, that might have been a coincidence caused by something else.

http://stuff.fredcooke.com/FreeEMS.Disconnected.Serial.Device.png [^]

 - Square blob on left is MTX with unplugged/missing device.
 - Rising slope on left is Gimp launching to take the screen shot.
 - Base CPU usage is MTX reading FreeEMS and displaying values in various ways.

Note, 2 cores, so the 50% reached is 100% of one. To me it looks like a busy wait loop in one thread without a sleep call checking for devices to re-appear.
User avatar (0000323)
Fred (administrator)
2011-09-27 18:36

I just unplugged the power from the jimstim and freeems because I'm going out and again, 100% of one core. This time it was the JimStim plugin, though. This time both devices were still there, just the actual end units that it was talking to were gone.
(0000324)
dandruczyk (viewer)
2011-09-27 20:02

normal behavior. its probably because your system has only 1 serial port or none, and thus it gets hungup.
User avatar (0000325)
Fred (administrator)
2011-09-27 23:55

Nope, it had two at the time, and eating 100% of the CPU in a loop doing nothing isn't cool, no matter what the app, last time I checked, there must be a solution, somehow, sometime. :-)
(0000326)
dandruczyk (viewer)
2011-09-28 01:01

It is not a high priority. Feel free to profile it to find the source of the spin and submit a fix. It doesn't crash right now and recovers as designed so its not a major issue and is a fringe case.
User avatar (0000327)
Fred (administrator)
2011-09-28 10:12

Question: If I hit ctrl C while it's doing this, I guess there is a higher than average chance of it being running the correct code at the time and that therefore the trace given will (possibly) be useful to find the source? If I do it 10 times, at least some of them will point at it, right? Or do I fail to understand gdb/c/threads/etc properly? Agreed that it's low priority.
(0000328)
dandruczyk (viewer)
2011-09-28 10:59

Ctrl-c IN WHAT CONTEXT dammit!!!!???? If in gdb it just stops. Info threads lists running threads. Thread x changes to that thtead. Bactrace tells u where u are. I.ve aleady done this and not found any tight spin zones..... the repair thread has appropriate sleep calls to prevent tight loops
User avatar (0000329)
Fred (administrator)
2011-09-28 11:27

The context was present, just implicit, hence you got it right. Good to know that you've done it. Good to know that it looks covered. I'll have a crack at trying to find it at some later date if you don't beat me to it first.
(0000330)
dandruczyk (viewer)
2011-09-28 11:34

No it was a guess but u need to be more thorough and utilize google instead of assuming im a mindreader
User avatar (0000331)
Fred (administrator)
2011-09-28 11:47

No, the sentence with ctrl C in it also had trace in it. Traces come from gdb, so it was implied. I could google, and waste hours, or I could ask the expert and get the response above that told me you've already done what I was planning and prevent me wasting my time.
(0000332)
dandruczyk (viewer)
2011-09-28 11:54

it most certainly did not
Quoting: 'Question: If I hit ctrl C while it's doing this, I guess there is a higher than average chance of it being running the correct code at the time and that therefore the trace given will (possibly) be useful to find the source? If I do it 10 times, at least some of them will point at it, right? Or do I fail to understand gdb/c/threads/etc properly? Agreed that it's low priority.'

The only thing that gives even an ambiguous hint is "while it's doing this" but even there was nothing stating something concrete like: "If i hit Ctrl-C in GDB's window, what does it do?", or if I hit "ctrl-C when mtx has focus it does blah..."

You are an abstract person and communicate with abstract (more ambiguous than they should be) statements, which leads to these huge wastes of time, so stop doing that and spell it out leaving NOTHING up to interpretation/assumption.
User avatar (0000333)
Fred (administrator)
2011-09-28 11:57

Relevant pieces in caps with double stars.

If I hit **CTRL C** while it's doing this, I guess there is a higher than average chance of it being running the correct code at the time and that therefore the **TRACE** given will (possibly) be useful to find the source?

Because I said trace, it is implicit, not assumed, that I'm running in GDB. I'm careful with my language usage, be more careful reading it.
(0000334)
dandruczyk (viewer)
2011-09-28 12:25

you still failed to state the context. How the hell do I know if you meants" you hit ctrl-c somepalce in mtx and it triggered a segfault that was visible as a trace in the gdb window? You DID nto state that, so it left it up to be assumed/inferred which introduces the chances for mis-interpretation and the requirement of clarification as well as the waste of both my and your time.

solution: you provide EXPLICIT context, not implicit. never assume the person you're writing too isn't half asleep, half blind, or 100% lazy, ALWAYS spell it out, the extra 8 words to begin with would have saved you 8 responses...
User avatar (0000335)
Fred (administrator)
2011-09-28 12:44

There is another solution, I stop providing bug reports.
(0000336)
dandruczyk (viewer)
2011-09-28 12:48

That's a choice you'll have to make. Be thankful you're not dealing with owen taylor from gnome, he'd rip you apart with your reports.
User avatar (0000356)
Fred (administrator)
2011-10-08 13:08

Tested, works as advertised in commit hash 6a39466d7f1b5196f3f610b2e59915653f085bde

Well done! :-)


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker