Re: AfterStep bug
Gregory D Lewis (glewis@maths.adelaide.edu.au)
Mon, 23 Nov 1998 06:28:55 +1030 (CST)
Ethan wrote:
>
> On Sun, 22 Nov 1998, Gregory D Lewis wrote:
>
> > I believe I have found a bug in AfterStep 1.5beta6 (I got the 1.5beta5 source
> > and patched things with all the patches up to 1.5beta-22-mihm-to_beta6.patch and
> > it now reports a verison of 1.5beta6). When using the default menus and the
> > like I hit "Start -> Desktop -> Update All" and found that the menus now
> > contained a lot of grayed out items with the word "nop" in them. I think this
> > is because files in the menu directory like 3_nop produce such a menu item
> > with the current code.
>
> Hmm. I don't see this behavior. I compiled AS 1.5beta6 via install.script,
> deleted my ~/GNUstep, restarted, and did "Start -> Desktop -> Update All".
> My menus look fine - I have no menu entries with the word "nop" in them.
> Can anyone else reproduce this?
My understanding of the code is that it does (while recursing through dirs):
Try and read each file
If I can read the file and it contains valid "stuff"
Write stuff into menu file
Else if the filename (without the #_) is a valid executable
Write Exec "foo" into menu file (assuming the file is #_foo)
Else
Write Nop "foo" into menu file
(which you probably already all knew :)
My start menu contains several #_nop files. 1_nop contains the text `Nop " "'
which produces a blank menu item correctly. 0_nop and 3_nop are blank files
however and end up in the final else of the code. I didn't see any .rej files
here during patching, so I assume they are supposed to be blank? I can
obviously just put the text `Nop " "' into the files and they will work as
planned. So maybe this is a feature rather than a bug? Depends if you want
a blank #_nop file to try and find an executable named nop or if you want it
to be a Nop menu item :).
>
> > I also have had the Pager crash a number of times. The trace always looks like:
> >
> > #0 0x20195704 in strncpy ()
> > #1 0x2ca81 in ?? ()
> > #2 0x200e6007 in WritePixels ()
> > #3 0x200e5ea9 in xpmWriteFile ()
> > #4 0x200e5ce5 in XpmWriteFileFromXpmImage ()
> > #5 0x200e5bd3 in XpmWriteFileFromImage ()
> > #6 0x200e6747 in XpmWriteFileFromPixmap ()
> > #7 0xb1a9 in ScalePagerBackground (Desk=0) at background.c:706
> > #8 0xb7c6 in MakeBackgrounds (Desk=0) at background.c:806
> > #9 0x499b in initialize_pager () at x_pager.c:419
> > #10 0x1b5a in main (argc=7, argv=0xefbfdd60) at Pager.c:271
>
> Pager is Sasha's baby - any ideas, Sasha? To me, this sounds like a bug
> in libXpm; the strncpy() in WritePixels() is copying data internal to
> libXpm.
Seems to occur for me with the initial setting of jpeg backgrounds. I also
use a jpeg background with my xdm configuration (which may or may not be
relevant).
--
Greg Lewis Applied Maths Department
Email : glewis@maths.adelaide.edu.au University of Adelaide
--
"If God lived on Earth, people would knock out all His windows."
-- Yiddish saying