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