Opened 9 years ago
Last modified 5 years ago
#12448 assigned bug
Firewire-0 cause troubles (GetBuffer: IDs mismatch, SetHeader)
Reported by: | vidrep | Owned by: | leavengood |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Servers/media_addon_server | Version: | R1/Development |
Keywords: | Cc: | ttcoder | |
Blocked By: | Blocking: | #9804, #11243, #12477, #12488, #12700, #13988, #14854, #14877 | |
Platform: | All |
Description (last modified by )
hrev49758 x86_gcc2 Media Add-on Server crash after deskop appears Debug report attached
--
When Firewire-0 is present there's a memory corruction supposedly caused by the driver. This is the master ticket.
Attachments (7)
Change History (40)
by , 9 years ago
Attachment: | media_addon_server-493-debug-07-11-2015-16-18-51.report added |
---|
comment:1 by , 9 years ago
comment:2 by , 9 years ago
Did a fresh install of hrev49833 x86_gcc2 on my second test PC pkgman full-sync to 49852 x86_gcc2 reboot media_add-on server debug report appeared on desktop after the reboot Was this automatically generated? I did not see any debugger dialog, nor did I input a command. debug report attached
by , 9 years ago
Attachment: | media_addon_server-624-debug-16-11-2015-19-03-21.report added |
---|
comment:3 by , 9 years ago
Blocking: | 12477 added |
---|
comment:4 by , 9 years ago
Milestone: | Unscheduled → R1 |
---|---|
Status: | new → assigned |
I think the common factor between all bug reports that I've seen is that the FireWire-0 control is there. This might be cause of some buffers mismatch or area offsets overflow since those threads live in the same team (the media_addon_server).
A test that might be useful is if you disable firewire from bios or blacklist the right drivers so that we can see if the problem is still happening.
comment:5 by , 9 years ago
I'm not so sure this issue is persistent enough to easily track down. I saw it happen only twice during a week in which I was at home on a work break, doing a lot of testing for Haiku. Prior to the first report, I had not seen a media_addon_server crash for quite some length of time. Of course, I'm always willing to assist however I can, to help Haiku progress toward a stable Beta release. I'll try your suggestion should the problem become reproducible.
comment:6 by , 9 years ago
I fixed different occurrences of this bug, only one of them was replicable on my system and it happened at very high load of the system (such as 20 videos played at the same time). I don't see this bug on my pc since then, and also I don't have a firewire. So if we could confirm that disabling it the bug doesn't occur, it will be helpful to finally fix the source.
comment:7 by , 9 years ago
Did a fresh install of hrev 49857 x86_gcc2 on my PC...
pkgman full-sync
reboot
media_add-on server wont crash anymore... Maybe fixed?! Strange...
comment:8 by , 9 years ago
Description: | modified (diff) |
---|---|
Summary: | Media Add-on Server crash → Firewire-0/SetHeader cause troubles |
comment:9 by , 9 years ago
Blocking: | 12700 added |
---|
comment:11 by , 9 years ago
Blocking: | 12488 added |
---|
comment:12 by , 9 years ago
Summary: | Firewire-0/SetHeader cause troubles → Firewire-0 cause troubles (GetBuffer: IDs mismatch, SetHeader) |
---|
For reference to anyone experiencing this bug, to fix the problem you should blacklist the fw_raw driver from the bootloader.
comment:13 by , 9 years ago
Blocking: | 11243 added |
---|
comment:14 by , 7 years ago
Blocking: | 13988 added |
---|
comment:16 by , 6 years ago
Resolution: | → not reproducible |
---|---|
Status: | assigned → closed |
comment:17 by , 6 years ago
Cc: | added |
---|
comment:18 by , 6 years ago
Resolution: | not reproducible |
---|---|
Status: | closed → reopened |
comment:19 by , 6 years ago
Blocking: | 14877 added |
---|
comment:20 by , 6 years ago
Blocking: | 14854 added |
---|
comment:21 by , 6 years ago
Just to confirm that blacklisting fw_raw works around the issue for me. Upgraded to 52979 today and media_addon_server was crashing. Rebooting did not help. My machine is a ThinkPad X60, which has a Firewire port; I'll keep it blacklisted as I don't have any Firewire devices. I've saved the crash report if that helps debugging the issue.
comment:22 by , 6 years ago
@vidrep - Issue still exists for R1B1 (up to -129 revision) and hrev53051.
NOTE: Firewire-0 control /boot/system/add-ons/media/firewire_dv.media_addon
Seems best to disable/blacklist it officially in the nightlies and future releases - until fixed.
The other thing I did was restart/quit the media server process - which should show media_server and media_addon_server when restarted. This gives a click sound in the speakers if it works OK - and no crash condition. Check that both app services are running.
comment:23 by , 6 years ago
I agree it should be disabled. I think I proposed it somewhere but there was someone which didn't agree and then for lack of motivation I postponed the thing.
However the patch is rather trivial, grep in the build directory for "fw_raw" and you will find what you need.
Sorry guys, not being formally an Haiku developer anymore I can't help more than that. Hope that helps!
comment:24 by , 6 years ago
Owner: | changed from | to
---|---|
Status: | reopened → assigned |
follow-up: 26 comment:25 by , 5 years ago
I believe this affects only the x86 32 bits version, not the 64 bits version. For me, it results in the media player not playing files (mp3) and Youtube not working in webpositive. debugger had shown, it happening on sysenter of comm_page for call on "volume control" or something similar. Still happening in hrev1/beta1 and hrev53176. Deactivating Firewire in BIOS has fixed the bug for me here in hrev1/beta1 32 bits.
comment:26 by , 5 years ago
Replying to dufresnep:
I believe this affects only the x86 32 bits version
Interesting, would you be able to confirm this?
by , 5 years ago
Attachment: | media_addon_server-503-debug-06-06-2019-09-57-00.report added |
---|
Bug while opening an mp3 file on latest (hvev53182) only happening in 32 bit version
comment:27 by , 5 years ago
Confirming with latest version (hrev53182), not happening in the 64 bits version (live USB key), but happening in live 32 bit version.
by , 5 years ago
Attachment: | MediaPlayer-526-debug-06-06-2019-13-18-54.report added |
---|
After updating the system, mp3 file playing
comment:28 by , 5 years ago
I installed the 32 bit version on an hard disk. Did the updates. Installed debugging packages. Now the mp3 file is playing, but a media addon bug still happen at the beginning (I just attached it to the bug). Now, acquire_sem_etc seems to be the one calling comm_page sysenter. Also, Firewire-0 thread seems not listed anymore.
comment:29 by , 5 years ago
I just tried to play a video on Youtube and got a more similar bug to the previous one, will attach it. Some strange thread names in it: thread 548: Yeah baby, very shagadelic thread 588: FireWire-0 control thread 879: Attack of the Killer Tomatoes
by , 5 years ago
Attachment: | media_addon_server-461-debug-06-06-2019-13-42-58.report added |
---|
after updates,GetBuffer: IDs mismatch,Attack of the Killer Tomatoe thread
comment:30 by , 5 years ago
I have rebuilt the system on my computer ( ./configure [no parameter] ). Wrote the nightly generated image to a usb stick. And strangely, the stick, although gcc2 32 bits one, play mp3 file find, and play youtube video(s) without any bug reports. So it might be related to the machine type?
by , 5 years ago
Attachment: | MediaPlayer-522-debug-07-06-2019-04-45-13.report added |
---|
regenerated system, segment violation in commpage_memcopy (fs=0x63)
comment:31 by , 5 years ago
I retried playing the same downloaded mp3 file, and now although the file is heard playing, I got a segment violation in commpage_memcpy. I have attached the file. Frankly unsure if it is related to this bug.
comment:32 by , 5 years ago
I got a similar bug as before on the regenerated system usb stick. Will attach it. I see Firewire0 stack is just over Audio Mixer control stack... is it possible it is overstacking inside Audio Mixer one?
6216 0x70a7b000 0x70ac0000 276 rw-s full HD Audio control_514_stack 5834 0x70cb9000 0x70cfe000 276 rw-s full System clock control_486_stack 6188 0x70ff2000 0x71037000 276 rw-s full Audio Mixer control_511_stack 6305 0x71212000 0x71257000 276 rw-s full FireWire-0 control_527_stack 5754 0x71466000 0x72467000 16388 rw-s full media_addon_server_480_stack 6224 0x724de000 0x72523000 276 rw-s full multi_audio audio output_516_st
by , 5 years ago
Attachment: | media_addon_server-480-debug-07-06-2019-05-34-23.report added |
---|
similar bug as previous (oops), on regenerated system usb stick (live mode)
comment:33 by , 5 years ago
Owner: | changed from | to
---|
That last debugger call is more or less the same as the one in the BufferCache: the buffer IDs do not match. So either buffers are getting mixed up in some way, or the header or buffer memory is being corrupted. Given they are shared all over the place corruption is a distinct possibility. Why it only happens on gcc2 is maybe the bigger question. It could be a locking bug where a couple things try to access the same buffer memory at the same time and one overwrites the other.
I almost have a handle on how the current buffer sharing works and can maybe come up with a better scheme, but with sharing memory across teams there is always a risk of corruption.
I think what I will do in the meantime for this issue is add to each of these debugger calls the buffer ID expected, and the one gotten.
Question for you dufresnep: is the firewire addon in use in some of your recent crashes?
Does the crash happened just after an upgrade? Or is it persistent?