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... > 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. -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
