Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000263TunixFreeEMS Pluginpublic2011-09-15 12:012012-03-30 20:40
ReporterFred 
Assigned Todandruczyk 
PriorityhighSeveritymajorReproducibilityrandom
StatusclosedResolutionunable to reproduce 
PlatformLinuxOSDebianOS VersionSid/Unstable
Product Version0.9.24-SNAPSHOT 
Target Version0.9.24Fixed in Version0.9.24 
Summary0000263: Fetching Tables Often Results In Wrong Data From Another Table
DescriptionI was just using the Advance table (on the mac mini, debian, fast) and I noticed that the values were wrong (from lambda, scaled to look lke advance). I hit fetch. I got other wrong values. I hit fetch again, I got the right values. Also, a BIG string of bad packets went past when doing this. I suspect that it's related to the threading issue in the other issue, but that is purely speculation. Certainly some data is getting corrupted in a threading context somewhere. I wonder if some change you have done has amplified an issue that was always there? Could it be related to 0000179 and that is in fact caused by heavy load during initial startup of MTX? I've not investigated on my side yet, this is more speculation.
TagsNo tags attached.
FirmwareVersionunknown, updating issue to appear in roadmap
Attached Files

- Relationships

-  Notes
(0000274)
dandruczyk (viewer)
2011-09-15 14:21

Fix the duplicate stop/start bytes as THAT IS a bug..
(0000291)
dandruczyk (viewer)
2011-09-26 00:39

Added a stupid sleep call sicne your ECU IS BROKEN and is issuing double stops/starts which opens a potential race condition when my end will begin sending while yours is still sending the final byte leading to a loss of a packet.
User avatar (0000295)
Fred (administrator)
2011-09-26 01:16

Actually, FreeEMS is listening before it even sends the first byte of its response. The receive buffer is cleared for receive before sending begins. I'll instrument it all in the next week or so and we'll KNOW what is going on, then. Closing this is fair enough, though, so I will. I can't reproduce it either, and couldn't before you put the sleep in, but it definitely occurred and the dropping packets thing is certainly no excuse for using the wrong data with the wrong tables when each packet has all the required info inside it.


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker