Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000410TunixJimStim Pluginpublic2011-11-19 14:172011-12-02 14:01
ReporterFred 
Assigned ToFred 
PrioritynormalSeverityminorReproducibilitysometimes
StatusassignedResolutionreopened 
PlatformLinuxOSDebianOS VersionSid/Unstable
Product Version0.9.24-SNAPSHOT 
Target Version0.9.24Fixed in Version 
Summary0000410: App sometimes locks solid when "stop sweeping" is pressed
DescriptionA "useless" bug report that you're forbidden from closing or assigning back, the consequence of which is no further bug reports from me.

Symptoms: no further button events accepted, no repaints done, no cpu used.

Haven't got a trace, may get one later, or when you hit me up for it on irc, don't send back, just absorb, think, stay calm, and if you can solve it, great, if not, i'll get a trace.
Steps To ReproduceStart a sweep in jimstim, press stop.
Additional InformationSeems to happen less if sweeping longer?
TagsNo tags attached.
FirmwareVersion
Attached Filespng file icon FuckedJimStim.png [^] (181,073 bytes) 2011-12-02 12:01

- Relationships

-  Notes
(0000619)
dandruczyk (viewer)
2011-11-19 17:25

Must have trace. Git hash, os and full context and steps to reproduce.......
User avatar (0000628)
Fred (administrator)
2011-11-19 21:15

Flag it, then.
(0000631)
dandruczyk (viewer)
2011-11-19 22:58
edited on: 2011-11-19 22:59

I cannot replicate this, even with multiple attempts, so you need to provide a trace and a corresponding it hash this applies to.

User avatar (0000651)
Fred (administrator)
2011-11-22 13:04

I tried yesterday and failed too. I'll assign it back if I find it, or close it if I give up.
User avatar (0000691)
Fred (administrator)
2011-11-25 00:41

Just saw this again, going to rebuild with debug and try to catch it, either tonight, or tomorrow, for sure.
User avatar (0000702)
Fred (administrator)
2011-11-25 17:31

OK, this happens when your JimStim gets powered off and on again while sweeping. The return from sweeping freezes using no CPU. I will get a trace soon, but this should lead you to the issue fairly rapidly without one if you have a device handy to try on. I have a few things to tidy up first, so no holding your breath :-)
User avatar (0000728)
Fred (administrator)
2011-11-28 14:27

I just tried to catch this behaviour, but with debug on and fatal warnings, it doesn't get that far, it doesn't get past iterrogation:

Starting program: /home/fred/MegaTunix/src/.libs/megatunix --g-fatal-warnings -p JimStim -P /dev/ttyUSB1
[Thread debugging using libthread_db enabled]
[New Thread 0xb0419b70 (LWP 14399)]
[New Thread 0xafc18b70 (LWP 14400)]
[Thread 0xafc18b70 (LWP 14400) exited]

Gtk-CRITICAL **: gtk_text_buffer_emit_insert: assertion `g_utf8_validate (text, len, NULL)' failed
aborting...

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb0419b70 (LWP 14399)]
0xb7fe2424 in __kernel_vsyscall ()
(gdb) backtrace
#0 0xb7fe2424 in __kernel_vsyscall ()
0000001 0xb6f91911 in raise () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
0000002 0xb6f94d42 in abort () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#3 0xb71805e8 in g_logv () from /lib/libglib-2.0.so.0
0000004 0xb7180622 in g_log () from /lib/libglib-2.0.so.0
0000005 0xb718081d in g_return_if_fail_warning () from /lib/libglib-2.0.so.0
0000006 0xb799f8a4 in ?? () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
0000007 0x0808df78 in update_logbar (view_name=0xb045be21 "interr_view", tagname=0x0, message=0x8356400 "Command \"Q\" (ECU Revision), returned 2 bytes (J\377)\n", count=0, clear=0,
    free=1) at notifications.c:213
0000008 0xb0430c97 in interrogate_ecu () at interrogate.c:194
0000009 0x080a1562 in thread_dispatcher (data=0x0) at threads.c:203
0000010 0xb71a0b6f in ?? () from /lib/libglib-2.0.so.0
0000011 0xb70c6c39 in start_thread () from /lib/i386-linux-gnu/i686/cmov/libpthread.so.0
0000012 0xb703396e in clone () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
Backtrace stopped: Not enough registers or memory available to unwind further
(0000781)
dandruczyk (viewer)
2011-12-01 03:49

I tested this by powering off the jimstim whilst sweeping and powercycling the jimstim as well as unplugging the fragile serial connection from it, as well as various combinations of power/start/stop/etc. And I can't trigger the freeze/hang no matter what I try...

Closing. If you can get a useful trace, feel free to reopen, but NOT until then.
(0000782)
dandruczyk (viewer)
2011-12-01 03:50

Closing, not replicatable. Feel free to re-open IF AND ONLY IF you can provide a definitive (useful) trace and a replication procedure.
User avatar (0000783)
Fred (administrator)
2011-12-01 09:03

Like fuck you're closing this!!! You requested a trace. I attempted to get one and was BLOCKED by another issue. At that point you need to either fix the other issue, for which I provided a trace, or advise how to avoid hitting it in the process of getting you a trace. The app wouldn't start up and talk to the JimStim in the debugger with fatal warnings on. It's NOT POSSIBLE to get your trace due to some other fault. Perhaps you didn't see the trace on here because of your mood due to 0000443, if not, read again and we'll take it from there.
User avatar (0000784)
Fred (administrator)
2011-12-01 09:05

Cut the shit, Dave. It's getting old fast.
(0000788)
dandruczyk (viewer)
2011-12-01 13:33

I CAN NOT REPLICATE THIS. I have spent several hours wasting my time on this already. Until you can get a me a USEFUL TRACE, not like hte bullshit you submitted about text not being UTF8 this issue will sit idle.

Go up and look at your trace. that is NOT a deadlock, its a glib warning because some string isn't UTF-8. For fucks sake use google and go read a howto on how to use gdb.

Even if you run it WITHOUT running under GDB and you deadlock it, you can STILL GDB it. (gdb -p <PID>), use "info threads" to list threads, and then "thread N" followed by "backtrace" to list the context of where each thread is sitting. a trace of EACH AND EVERY THREAD in the case of a deadlock is necessary.

You should ALWAYS be using a debug build (./configure --enable-debug), otherwise you won't get line numbers in the trace and the traces will be USELESS TIME WASTING GARBAGE, and it will be noted with prejudice in the ticket!

Reassigning this back to you, when you get info put it in and reassign, otherwise, stop bouncing this to me, when I CAN NOT REPLICATE your major malfunction. This is a never-ending issue with your reports, they are hardly ever verbose enough, rarely if ever have context or complete context, nor a replication procedure, and I've yet to see notes in your various issue tickets if it's an all-the-time occurence or once every N times. Stop wasting your own time with vague reports.
User avatar (0000790)
Fred (administrator)
2011-12-01 13:46

THAT ^^^ is what the first reply post my trace should have said. I don't have time to dig through your traces for you when I don't know what they mean. I get a trace, you read it, that's how it works. Additionally, YOU told me to run --g-fatal-warnings, thus that is what you get. If you don't want that, let me know and I can run it without (it sounds like this is the case?). I CAN NOT KNOW what you want. You MUST TELL ME CLEARLY what you need so that I can get it for you. I'm no mind reader. Stop whinging that the reports aren't good enough and start helping ME get YOU the info that YOU need to fix YOUR code. This is solely a benefit to you and your reputation as a dev, issue trackers are designed to be a channel of feedback and information to you from users. RIght now it's ONLY me filling them out. No one else appears to give a shit. If you keep being a cock about my reports I'll simply stop making them and write my own tools. No big deal. PC side stuff is infinitely easier and faster to develop than embedded stuff. Certainly faster than dealing with your abuse on a daily basis :-)
(0000792)
dandruczyk (viewer)
2011-12-01 15:01

That hardly even warrants a response. You repeatedly show you don't even want to think through a problem you run into, and you immediately give up and regurgitate a limited amount of whatever you see without even investigating further or trying variations. This wastes everyone's time and doesn't HELP anyone.

Like I said I have tried to replicate this and it DOES NOT HAPPEN for me at all, so you need to try harder and either RE-TEST and think before you just give up, or just close it as a fluke particular to your setup/machine/hardware combination.
User avatar (0000794)
Fred (administrator)
2011-12-01 15:24

Actually, David, I spent significant time on this issue trying and retrying until I understood how to reproduce it and describe that to you. Then I did just that. First thing the next morning I followed your instructions to the letter and gave you the result. You then ignored my post with the trace and closed the issue rather than replying telling me how to get you one that was more useful - that was unacceptable. I communicated that to you, and only then, this morning, a few hours ago, did you give me the information required to provide useful information for you. I did not know, and will not remember such information. However, if you draft up some HTML describing all of the possible ways to debug MTX FOR YOU, then I will host it for you. Or you could write that info up in a thread on the forum. In any case, it is not efficient to repeat it 40 times for 20 users twice each, document it. Now that I have the information, once I've tested OLV for ben, and my own most recent changes, I will test this for you on the same version. Before I do that though, I require that you answer my simple question as stated above.

"Additionally, YOU told me to run --g-fatal-warnings, thus that is what you get. If you don't want that, let me know and I can run it without (it sounds like this is the case?)."

Is that the case, or not?

As for me not wanting to spend a lot of time on this, you're right! I have lots of other things to spend time on. You get a slice, as does Ben, as does Sean, as does the forum, as does the server, as does the wife, no one gets left out, no one gets more than they deserve. It would be a horrible waste of my time, to everyone's great loss, if I spent more time on C stack traces than what it takes to copy/paste them to you. I don't know what to do with them, at all. You do. I'm just a tester, not a dev, for MTX, in your eyes, in this context. Treat me like I don't know shit, and you'll get good results. If you treat me like that in other contexts, you'll get a different response. Don't try it.

I'll use the almost-too-late instructions above to get you a trace a little later after higher priority items such as eating lunch and scratching my left ear. You can write up the same stuff and more, consolidate it in one place and post it somewhere or send me HTML to post for you. This will benefit everyone as debugging MTX for you will no longer be a mystery.
User avatar (0000826)
Fred (administrator)
2011-12-02 10:44

Sadly, I can't test this anymore, my JimStim appears to have shat itself. I've checked for all of the things that I've done wrong in the past and they all seem fine. It's like it wants to live, though, with "JimSt" coming out every now and again.

Command "C" (MS Clock), returned 1 bytes
Command "A" (MS-I Runtime Vars), returned 2 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Command "V" (MS-I VE/Constants), returned 5 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Command "A" (MS-I Runtime Vars), returned 2 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Command "A" (MS-I Runtime Vars), returned 1 bytes
Command "Q" (ECU Revision), returned 2 bytes (Ji)
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Command "A" (MS-I Runtime Vars), returned 3 bytes
Command "V" (MS-I VE/Constants), returned 1 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Command "A" (MS-I Runtime Vars), returned 1 bytes
Command "V" (MS-I VE/Constants), returned 4 bytes
Command "S" (ECU Signature), returned 1 bytes (J)
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "A" (MS-I Runtime Vars), returned 3 bytes
Command "V" (MS-I VE/Constants), returned 5 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Command "A" (MS-I Runtime Vars), returned 3 bytes
Command "V" (MS-I VE/Constants), returned 4 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Command "V" (MS-I VE/Constants), returned 1 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "A" (MS-I Runtime Vars), returned 2 bytes
Command "V" (MS-I VE/Constants), returned 4 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "S" (ECU Signature), returned 2 bytes (Ji)
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Command "A" (MS-I Runtime Vars), returned 2 bytes
Command "V" (MS-I VE/Constants), returned 1 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Command "A" (MS-I Runtime Vars), returned 4 bytes
Command "V" (MS-I VE/Constants), returned 4 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Command "A" (MS-I Runtime Vars), returned 2 bytes
Command "V" (MS-I VE/Constants), returned 1 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "A" (MS-I Runtime Vars), returned 4 bytes
Command "V" (MS-I VE/Constants), returned 2 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Command "A" (MS-I Runtime Vars), returned 3 bytes
Command "V" (MS-I VE/Constants), returned 1 bytes
Command "S" (ECU Signature), returned 1 bytes (J)
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "A" (MS-I Runtime Vars), returned 2 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Command "A" (MS-I Runtime Vars), returned 5 bytes
Command "V" (MS-I VE/Constants), returned 1 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Command "V" (MS-I VE/Constants), returned 1 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Command "A" (MS-I Runtime Vars), returned 2 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "A" (MS-I Runtime Vars), returned 1 bytes
Command "V" (MS-I VE/Constants), returned 3 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Command "A" (MS-I Runtime Vars), returned 2 bytes
Command "V" (MS-I VE/Constants), returned 5 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Command "A" (MS-I Runtime Vars), returned 1 bytes
Command "V" (MS-I VE/Constants), returned 5 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Command "Q" (ECU Revision), returned 1 bytes (J)
Command "V" (MS-I VE/Constants), returned 4 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "V" (MS-I VE/Constants), returned 4 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "C" (MS Clock), returned 1 bytes
Command "A" (MS-I Runtime Vars), returned 6 bytes
Command "V" (MS-I VE/Constants), returned 4 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "A" (MS-I Runtime Vars), returned 1 bytes
Command "V" (MS-I VE/Constants), returned 1 bytes
Command "S" (ECU Signature), returned 5 bytes (JimSt)
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
USER Initiated ECU interrogation...
Command "A" (MS-I Runtime Vars), returned 3 bytes
Firmware NOT DETECTED, Enable Interrogation debugging, retry interrogation,
close megatunix, and send ~/MTXlog.txt to the author for analysis with a note
describing which firmware you are attempting to talk to.
User avatar (0000829)
Fred (administrator)
2011-12-02 12:02

Uploaded screen shot clearing MTX of blame with latest JimStim fucking BULLSHIT. Not impressed!
(0000840)
dandruczyk (viewer)
2011-12-02 13:44

Stupid suggestion, but unplug/replug your USB adapter. or unplug, remove kernel module(s) for it and replug. I'v found my FTDI adapter is throwing kernel panics occasionally, and replugging of the adapter is required to make it behave again.
User avatar (0000843)
Fred (administrator)
2011-12-02 14:01

It might be as you describe at the beginning of your suggestion because I took that reading in the screen shot on the CPU side of the FTDI. I might try it later, but I got the result I needed by hacking the firmware to behave badly :-)


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker