GNOME Bugzilla – Bug 334715
core dump switching between 32 bit and 64 bit
Last modified: 2006-03-28 19:21:06 UTC
I notice that the GStreamer 0.10 registry files get generated differently if I log in via 32-bit mode or 64-bit mode. Not sure why the files should differ. The problem I notice is that after creating the files in one mode and then switching, this causes the files to get corrupted (I have to delete the $HOME/.gstreamer-0.10 directory to get them to rebuild right), and also causes the panel to crash. I'm attaching the registry files generated when running GNOME in 32 bit mode, and then in 64 bit mode. I've also attached the corrupted files that get generated after switching from 64bit to 32bit.
Created attachment 61329 [details] gzipped working 32-bit registry This is a gzipped working 32-bit registry file
Created attachment 61330 [details] this is a working 64-bit registry this is a working 64-bit registry
Created attachment 61331 [details] this is a gzipped registry after switching from 64 to 32 bit, corrupted this is the registry after switching from 64 to 32 bit, and shows the corruption
Can you retest with a recent core (0.10.4, or cvs)? I rewrote the registry-writing code to actually check that writes worked; also the registry reading code should now never abort, no matter how badly corrupted the registry is, so the worst case will be that it'll end up doing registry rebuilds that it shouldn't need. If that doesn't help, I really have no idea - if you could run a debugger and figure out where the bad writes are coming from that would be helpful. Also, really, you should have completely independent registry files for 32 and 64 bit modes (you might have quite a different set of plugins available), the registry file should be called registry.arch.xml (with 'arch' replaced by some architecture name - I get 'i486' or 'i686' depending on how gstreamer has been built, for instance), you should have a similar distinction for 32/64 bit mode. Maybe that wasn't in 0.10.1, though. Anyway, since a) the bug will hopefully be gone, and b) current core should have two different reasons to never trigger this case if the bug _isn't_ gone, I expect this is fine now.
The person who I submitted this bug for has reported that the problem has gone away now that they have upgraded to the latest GStreamer code. Thanks for responding.