XScreenSaver 5.10 out now

XScreenSaver 5.10 is out now. I think I have fixed the color and crashing problems on MacOS 10.6.

I'm still curious to hear from someone who has tried to run this on 10.4 PPC.

Let me know how it works...

Tags: , , , ,

19 Responses:

  1. scullin says:

    > I'm still curious to hear from someone who has tried to run this on 10.4 PPC.

    I was going to get back to you on that, except it turns out my old laptop is running 10.3. Did you know your home page is completely unusable in Safari 1.3? I'm sure that stings.

    I know I have a 10.4 disk somewhere...

  2. lifftchi says:

    Colors in loaded .jpgs on ripples, zoom, and glslideshow look fine. PPC, 10.4.11.

    It is also slow like a dog on my 1 GHz G4 imac, but that is not surprising.

  3. cavorite says:

    Works fine so far on my G4 1.5ghz powerbook running 10.4.11

  4. dzm6 says:

    Pointing any of the image-related savers to a directory containing 5000+ images (in sub-directories), all in the 6+ "megapixel" range, is somewhat guaranteed to crater the machine for the next twenty minutes. Carousel, for example, will sit on "Loading Images...", cause the fans to spin up, etc. While this is happening no mouse or keyboard activity interrupts.

    • jwz says:

      What it's doing is pretty straightforward -- it's just listing the directory and cacheing the result for 3 hours -- and hasn't changed. Try doing it by hand verbosely:

      ~/Library/Screen\ Savers/Carousel.saver/Contents/Resources/xscreensaver-getimage-file -vv ~/Pictures/YOUR_PICTURES_DIR

      • dzm6 says:

        Yep. That's the cratering.

        FWIW the manual run tells me that there are 9275 files in the cache. Each of the XScreenSaver modules has its own pref for what directory to look in for images (but they all share the same cache file), and selecting a saver from the "Preview" list in System Prefs causes the exisitng cache file to be thrown away and a new one built IF the image dir value is different.

        I would be really spiffy if the cache lifetime could be set outside of the script itself, and it would be spiffy if there were a single spot that one could use to set the image dir for all savers. I suspect that there's a way to twiddle ~/.xscreensaver to make this happen.

        • jwz says:

          But why is it taking so long? Because on my machine, with 30k+ images in the directory, it only takes a few seconds on the first run, and is instantaneous on subsequent runs in the same dir (after deleting the cache file).

          The MacOS saver framework doesn't allow you to share preferences between screen savers. They each get their own plist file. That's how it's done.

          • dzm6 says:

            I wish I knew why it was taking so long. Doing something as simple as this:

            find ~/Pictures/Pics/Processed/ -name "*jpg" > /tmp/cache

            takes well less than a second to process and happily finds 9243 images. I can find no good reason for why the perl script craters so badly. I don't see obvious CPU use, nor obvious memory problems. The machine (a year-old MacBook Pro) just slows to a crawl, the fans start blowing, and the hard drive thrashes.

            When I ran the command you mentioned by hand the run was (usually) nearly instantaneous. Sometimes it cratered though:

            xscreensaver-getimage-file: - found file /Users/.../DSC_1857.jpg
            xscreensaver-getimage-file: - found file /Users/.../DSC_1858.jpg
            xscreensaver-getimage-file: f=9275; d=577; s=1962; skip=2614+1386=4000.
            xscreensaver-getimage-file: cached 9275 files

            ^CSegmentation fault

            I had let it sit thrashing for over ten minutes before I ^Cd it.

            (Paths shortened to make your window Not All Wide)

            • jwz says:

              Well, I was gonna say "try adding -type f to find to make sure it stats all the files" but looking at the perl code, it's pretty smart about only statting once it needs to know if it's dealing with a directory, which is exactly what find does.

              Segmentation faults in Perl are pretty damned far from being something I can do anything about.

              Did it sit there for 10 min silently with -vv? Because that would be weird. Try it under truss maybe?

              • dzm6 says:

                Welp ... truss for OSX seems to be eluding me. I found a dtruss that seems, under the covers, to be using DTrace, won't accept the -o switch that truss and strace like, and basically makes me angry. No joy there.

                I notice that ~/Library/Logs/DiagnosticReports/ has many crash reports for perl. As you said - not much you can do if this is perl being stupid.

                On the off chance the perl crash IS useful to you, the important bit looks like:

                Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
                Exception Codes: KERN_INVALID_ADDRESS at 0x00000001007ffff0
                Crashed Thread: 0 Dispatch queue: com.apple.main-thread

                Thread 0 Crashed: Dispatch queue: com.apple.main-thread
                0 libSystem.B.dylib 0x00007fffffe00ef3 __memcpy + 1875
                1 libperl.dylib 0x000000010007b2e2 Perl_sv_setsv_flags + 2796
                2 libperl.dylib 0x00000001000810ad Perl_newSVsv + 153
                3 libperl.dylib 0x00000001000e3d6e Perl_pp_sort + 3120
                4 libperl.dylib 0x000000010006e6cc Perl_runops_standard + 42
                5 libperl.dylib 0x000000010006e43a perl_run + 480
                6 perl5.10.0 0x0000000100000da4 main + 228
                7 perl5.10.0 0x0000000100000cb8 start + 52

                This also seems to be happening AFTER the cache file has been created. I can tickle the bad behavior at will be removing


                , then running the manual creation process. If I then let it spin until crash OR ^C out of it


                exists and appears to be a complete listing of what's supposed to exist. Subsequent runs of the create thinger then work more-or-less as expected:

                [dzm@DzM Resources]# ~/Library/\Screen.../xscreensaver-getimage-file -v\
                xscreensaver-getimage-file: recursively reading ~/Pictures/Pics/Processed...
                xscreensaver-getimage-file: f=9275; d=577; s=1962; skip=2614+1386=4000.
                xscreensaver-getimage-file: cached 9275 files
                [dzm@DzM Resources]# ~/Library/\Screen.../xscreensaver-getimage-file -v\
                xscreensaver-getimage-file: 9275 files in cache
                xscreensaver-getimage-file: /Users/.../misc0093.jpg: 3614 x 2445
                [dzm@DzM Resources]#
                [dzm@DzM Resources]# ~/Library/\Screen.../xscreensaver-getimage-file -v\
                xscreensaver-getimage-file: 9275 files in cache
                xscreensaver-getimage-file: /Users/.../DSCN0923.JPG: 2272 x 1704
                [dzm@DzM Resources]#
                [dzm@DzM Resources]# ~/Library/\Screen.../xscreensaver-getimage-file -v\
                xscreensaver-getimage-file: 9275 files in cache
                xscreensaver-getimage-file: /Users/.../dsc_9017.jpg: 1960 x 3008
                [dzm@DzM Resources]#
                [dzm@DzM Resources]# ~/Library/\Screen.../xscreensaver-getimage-file -v\
                xscreensaver-getimage-file: 9275 files in cache
                xscreensaver-getimage-file: /Users/.../cathedral4.jpg: 1024 x 768

                (Paths once again shortened).

                I've also noticed that Finder sluggishly tells me that I loose around 1.3G of my free HD space while the thrashing is happening, but when I finally manage to break out of the badness the missing space is returned to me.

                My best (and not very good) guess right now is that this has something to do with releasing the lock that is being created.

                I should also mention, though I suspect it is not relevant, that this machine is running a release slightly newer than 10.6. Unfortunately I don't have a vanilla 10.6 install handy with which to poke.

                (Sorry for the multiple re-posts. The PRE lines were way too wide and had to be fixed.)

                • dzm6 says:


                  my $use_spotlight_p = 0;


                  my $use_spotlight_p = 1;

                  makes the pain go away.

                  • jwz says:

                    You will have entirely other pain, like, "why are most of my images never being found".

                  • dzm6 says:

                    That will make me sad.

                    Damn. I thought I was onto a solution.

                  • dzm6 says:

                    Found the bug. Sort of.

                    It's in the sort().

                    Commenting out

                    @all_files = sort(@all_files);

                    makes the pain go away.

                    This seems to be a bug in the perl 5.10.0 in /usr/bin/perl:

                    # /usr/bin/perl -v

                    This is perl, v5.10.0 built for darwin-thread-multi-2level
                    (with 2 registered patches, see perl -V for more detail)

                    Changing the #! line of the script to point at the perl installed by MacPorts makes the sort() badness go away:

                    # /opt/local/bin/perl -v

                    This is perl, v5.8.9 built for darwin-2level

                    I'll file a bug with Apple.

                  • jwz says:

                    Well. One can't expect new technology like sorting to be completely worked out yet.

                    I wonder if this somehow has something to do with why makedepend sometimes never terminates. Though that doesn't seem to run perl.

                  • dzm6 says:

                    A b00g is filed.

                    Incidentally it seems as though perl 5.8.9 and 5.10.0 are present in /usr/bin. I was able to work around this problem by:

                    sudo rm -rf /usr/bin/perl
                    sudo ln -s /usr/bin/perl5.8.9 /usr/bin/perl

  5. pfrank says:

    I'm getting lots of crashing from these on 10.5.8 on Intel FWIW. I can paste in the crash reports if that would help.

    • jwz says:

      Sure. I don't need the whole logs, just the first few lines of the backtrace of the thread that crashed.

      • pfrank says:

        Not sure if this is the necessary bit:

        Application Specific Information:

        Thread 0 Crashed:
        0 libSystem.B.dylib 0x971e3e42 __kill + 10
        1 libSystem.B.dylib 0x9725623a raise + 26
        2 libSystem.B.dylib 0x97262679 abort + 73
        3 org.jwz.xscreensaver.CubicGrid 0x18549ab2 switch_to_resource + 449
        4 org.jwz.xscreensaver.CubicGrid 0x18549be7 bind_switch_to_preferences + 31
        5 org.jwz.xscreensaver.CubicGrid 0x1854a441 make_checkbox + 790
        6 org.jwz.xscreensaver.CubicGrid 0x1854cd88 traverse_children + 965
        7 org.jwz.xscreensaver.CubicGrid 0x1854e30b -[XScreenSaverConfigSheet initWithXMLFile:options:controller:] + 702
        8 org.jwz.xscreensaver.CubicGrid 0x18550a13 -[XScreenSaverView configureSheet] + 308