[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: trouble with 1.15.2
From:       walter harms <wharms () bfs ! de>
Date:       2009-11-27 8:16:34
Message-ID: 4B0F8AE2.1020501 () bfs ! de
[Download RAW message or body]



Denys Vlasenko schrieb:
> On Thursday 26 November 2009 18:30, walter harms wrote:
> > walter harms schrieb:
> > > Denys Vlasenko schrieb:
> > > > On Wednesday 25 November 2009 17:56, walter harms wrote:
> > > > > hi list,
> > > > > i am still trying to find the bug but i noted something more disturbing.
> > > > > With the move from 1.14.4 to 1.15.0 i found that my startup started sending \
> > > > > a bunch of 0 bytes to the terminal. This is gone unnoticed so far as that \
> > > > > we do not see the hexvalues
> > > > Do you see it when you build the same .config on x86?
> > > no, the bug seems to appear only while booting my embedded system (where i can \
> > > reproduce it with 100%). I have experiment with an older bb and starting bb \
> > > 1.15 later but where unable to get the bug this way (i did not try hard but the \
> > > bug is not obvious), 
> > > for now only bb has this problem none of the other programmes running seem to \
> > > be affected. 
> > > > > of the startupmessages. (i used them to see the bug above).
> > > > > It would be nice if someone would check that so i can get a second opinion.
> > > > > 
> > > > > I strongly suspect ash.c for the above behavior as that replacing the \
> > > > > 1.15.2 ash.c with 1.15.1 restores the old bug.
> > > > What is the old bug?
> > > 
> > > booting= starting linuxrc, the kernelmessages are not effected
> > > 
> > > short overview:
> > > 1.15.2            *    spurious 0x81 or 0x88 while output , crash
> > > 1.15.1            *    huge block of 0x00 while booting
> > > 1.15.0            *    huge block of 0x00 while booting
> > > 1.14.4            *    seems ok so far
> > > 
> > > cp ash.c from 1.14.4 to 1.15.0 makes the block of 0x00 disappear
> > > 
> > > I will try to bisect the problem (when i run into git problems).
> > > 
> > > there was also the question regarding the gcc we use:
> > > gcc version 3.2.1 Axis release R64/1.64
> > > 
> > > the strange thing is these block of 0x00 what is only visible if you
> > > send the system output directly into xxd (or od). It is possible other
> > > people have the same problem but do not realize it because they never
> > > see the real output only what appears on screen.
> > > 
> > > /*
> > > i suspect the new utf8 support but that is only related to
> > > the 0x8x i see in the latest version.
> > > */
> > > 
> > > 
> > > > I am somewhat confused now what do you see with which version.
> > > > 
> > > hope that helps,
> > > wh
> > hi denis,
> > 
> > i did some experiments with 1.15.0 and found it has nothing to do with FAST_FUNC \
> > or any buildin functions. But i was able to untrigger the bug with #define DEBUG \
> > 1 and reenable it with #define DEBUG 0 does this ring a bell ? (i start to \
> > believe there is dangling pointer).
> 
> You may find out which code patch is it by leaving #define DEBUG 0
> but replacing #if DEBUG by #if 1 in ash.c one-by-one,
> until you fin minimal set of such #if statements which need
> to be turned on to stop the bug from happening.
> 
> Hopehully there will be just one such #if, but be prepared
> that you might need to enable more than one...

franky i suspect DEBUG to be innocent it will provide somehow memory
that can be trashed without causing that damage i see. NTL it is the
only hint i have so far.


> > unfortunately i still see only tags until 1_13_4;
> > can you provide me with patches from ash 1.14.4 to 1.15.0 ?
> 
> After MUCH googling, I found this to be useful:
> 
> git log -p shell/ash.c
> 
> in checked-out current git spews out patches which touch ash.c
> in reverse chronological order.


this looks usefull, the only thing i miss are the 1_14_4 and 1_15_0 tags :)
There will be a day when i find out what happened ...

re,
 wh
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


[prev in list] [next in list] [prev in thread] [next in thread]