Bugzilla – Bug 3744
crash saving player remote options
Last modified: 2008-09-15 14:39:24 UTC
This is the last thing in the logs, but it may not be related. There was an error message on the server's screen that the Perl interpreter had crashed, so it may have been a nasty one. 2006-07-13 12:55:04.7722 Use of uninitialized value in delete at C:\Program Files\SlimServer\server/Slim/Networking/Select.pm line 106. 2006-07-13 12:55:04.8274 Use of uninitialized value in hash element at C:\Program Files\SlimServer\server/Slim/Networking/Select.pm line 82.
Were you changing the JVC/slimserver settings, then? Did you see any other strange behavior before that, or try to do anything unusual? I can't seem to repro this one.
Yes, I was adding jvc_dvd (I think I'd removed it some time ago) for no particular reason, just poking around. That's when it crashed. I see now that the checkbox is missing, so the changes weren't written to the prefs file.
Well, I'll leave this open for a bit as I try a few things.
Chris, try this to reproduce: Make *two* changes to the remote settings. I'm seeing crashes 100% of the time on the second one.
Whoa. I'm still not seeing a crash, but I definitely see some strange behavior. If I hit 'Change' once after making a change, the change appears to take place correctly. However, if I hit change twice, both boxes will be cleared. If I enable one remote, and hit 'Change' then enable the other and hit 'Change', the first box gets cleared, but the new change takes effect as I would expect. There's definitely something wrong with the remote state.
KDF - any thoughts here? Jim - the Networking/Select lines are harmless.
this is new... I can certainly recreate the crash. make a change, hit change a few times, make another change, hit change and it's gone. the fun part: nothing at all in the log. command line shows only segmentation fault. maybe more specific: turn off jvc remote, change, it should now show slim devices on, jvc off. restart server go back into player settings->remote it shows slim on, jvc off. turn jvc on, click change, jvc will show on click change, jvc now shows off click jvc on, click change...segfault.
Run it under perl -d ?
A little more info. It's not SlimServer crashing, but the ActiveState Perl interpreter. This is the error being recorded in the Windows XP Application event log: Faulting application perl.exe, version 5.8.7.813, faulting module syck.dll, version 0.0.0.0, fault address 0x00008194. YAML::Syck? http://search.cpan.org/dist/YAML-Syck/
using perl -d, just hangs. last debug msg with d_prefs d_ir: 2006-07-14 17:28:58.1364 Setting prefs irsetlist 1 equal to 1 perl using 100% cpu.
what is odd here is that irsetlist is not a pref that we should be writing out. disabledirsets is the pref, which stores the filename of the .ir files that should be ignored. I haven't had much time to look, but I can't see yet where this might be getting written out. The irsetlist pref in Setup.pm has the dontSet param set to 1, but maybe that's being ignored. If this is global, then there would also be problems with plugins checklist, rescan, file conversions, and debug settings.
main problem seems to be related to trying to enable a previously disabled irset. I am heading out for the evening, but I'll try and take a look when I'm back if no other ideas come through.
I'm not able to get anything useful from debugging. Sometimes it works, sometimes it doesn't. It never seems to crash any more even with the same steps and same code. At one point I was unable to re-enable any disabled remote, then it started working again. Enabling doesn't always seem to stick. Some refreshes go back to unchecked etc. i can't get a pattern from it, nor can I find anything helpful using Data::Dumper. I wonder if all the prefs were hammered a bit, if we wouldn't find this happening in several other places too.
I just blew it up in both the Internet Radio checkboxes and the Plugins checkboxes. Same syck.dll fault in the event logs. Haven't made it fail except with checkboxes. Plugins fails straight away, while the Internet Radio checkboxes either fails or I get the same sort of thing mentioned above - checks appearing and disappearing when they weren't touched.
Here's something else that is probably this same bug, or maybe a logic problem elsewhere. Having recently done a new checkout of the current trunk I wasn't able to stream to a remote Softsqueeze client from my FLAC library using a compressed stream. I figured out that the problem was that I'd forgotten to install LAME in the new installation. So I copied lame.exe over to the bin/mswin32 folder. Then I needed to enable it in the file types, as I could see that all of the MP3 stream format lines were unchecked. But I could not for the life of me get the FLAC > MP3 setting to stick. Also managed to crash SlimServer twice in the course of about a dozen attempts to check off this box. In my prefs I had the following: disabledformats: - flc-mp3-*-* - mov-mp3-*-* - mpc-mp3-*-* So I shut down the server, removed the '- flc-mp3-*-*' and '- mov-mp3-*-*' lines and the problem was fixed.
So is this sounding like a corrupt prefs file.. or?
unlikely corrupt prefs. I can make the checked remote option disappear on both linux and win2k just by pressing change a second time after checking a previously unchecked box. I also deleted prefs file, got the same results with a default prefs file on win2k. It also crashed Perl: Application popup: perl.exe - Application Error : The instruction at "0x02358194" referenced memory at "0x00000000". The memory could not be "read". I think this is going to involve a very long regression test to find out where it broke.
The only thing I can think of right now (granted it's early), is to upgrade YAML::Syck to the latest version.
*** Bug 3821 has been marked as a duplicate of this bug. ***
Change 8704 updates the version of YAML::Syck. Can you see if that fixes this crash? Thanks
I haven't been able crash it, so it looks like the page fault issues have been fixed. But I'm still seeing the flakey checkbox behavior. Any chance this might have been two bugs - a crashing problem with YAML::Syck and a logic problem in the SlimServer setup code dealing with checkboxes?
Quite possibly it could be two issues. The setup code that handles the checkboxes is in dire need of a rework. However, I'm more concerned about the crashing at this point.
used to work, now it doesn't. it needs to be reverted somewhere (I suspect not so recent 'optimisations') and fixed at least until total rewrite comes along.
Subject: Re: crash saving player remote options >used to work, now it doesn't. it needs to be reverted somewhere (I suspect not >so recent 'optimisations') and fixed at least until total rewrite comes along. What changed in this area recently?
I'm not sure it was that recently. The crash makes it obvious, but the funky checkbox stuff might be older. A lot of the checkbox pref stuff used to rely on preEvals, which started being removed and rehandled after change 6885. test plan...fresh checkout at that level and test the checkboxes. I'll update 200 at a time and see when it breaks. IF it isolates to 6885-7000, then we shoudl bug moser about ideas as to where it broke. If it doesn't isolate there, it might give a clue how to fix. If it still exists at 6885, then we'll need to prioritise rework of the checkbox prefs.
r6885 seems to be ok. clicking change over and over keeps the value just fine, as well as checking an empty box causing no crashes.
narrowed it down to somewhere between 7192 and 7205. unfortunately around 7200, many revs are no good due to some @INC changes and order of module loading.
looks like I'm the goat on this one, though for all of the attempts to figure out why, I'm lost as to why the routine to build the response message got in the way of the pref setting. change 8709 should fix the checkbox problems. please update and confirm.
well, this seems to work for me now. please reopen if anyone is having an issue with it.