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