trouble with 1.15.2

[walter harms]

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