It basically sets a rlimit, signal handlers, tries to make printf fail
intentionally, expects printf to fail with ENOMEM but instead it gets
a sig11 which gets handled and something gets stuck along the way when
exit'ing :)

http://pastie.org/2106361 is the code in question.

/Carsten


2011/6/22 Ulf Hofemeier <[email protected]>:
> That's exactly what I said yesterday. I'm not sure what "checking whether 
> printf survives out-of-memory-conditions" is doing. I remember there used to 
> be an issue with rpmbuild reverting to single byte reads() rather than doing 
> 4k packages for ARM. This means the building would actually work, but is by 
> an order of magnitude slower, which will result in OBS eventually killing the 
> build process it runs into a timeout.
>
> On Jun 22, 2011, at 6:37 AM, Carsten Munk wrote:
>
>> We're still investigating, but the good news is that the qemu problem
>> seems reproducable, and happens even on qemu git, linaro, qemu-meego
>> and all these.
>>
>> Will follow up when I have something more - it seems like some
>> mishandling of signals/out of memory conditions.
>>
>> /Carsten
>>
>> 2011/6/22 Carsten Munk <[email protected]>:
>>> Thanks for letting me know,
>>>
>>> I'll query around a bit with qemu maintainers.
>>>
>>> /Carsten
>>>
>>> 2011/6/22 Hofemeier, Ulf <[email protected]>:
>>>> Carsten,
>>>>
>>>> Latter one. I can eventually aborted the build for gzip and m4 after
>>>> nothing had happened for hours, but that was yesterday and it happened
>>>> again today.
>>>> Ulf
>>>>
>>>> On 6/21/11 9:30 PM, "Carsten Munk" <[email protected]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> qemu: Unsupported syscall: 369
>>>>> qemu: Unsupported syscall: 369
>>>>> qemu: Unsupported syscall: 369
>>>>>
>>>>> is the one you refer to?
>>>>>
>>>>> Or:
>>>>>
>>>>> checking whether printf survives out-of-memory conditions...
>>>>> /var/run/obs/worker/1/build/build: line 1261: 27071 Killed
>>>>>     chroot $BUILD_ROOT su -c /.build.command - $BUILD_USER <
>>>>> /dev/null
>>>>>
>>>>> (I see that in m4, gzip)
>>>>>
>>>>> /Carsten
>>>>>
>>>>> 2011/6/22 Carsten Munk <[email protected]>:
>>>>>> I'll try to see if I can catch the qemu errors - when there's any ARM
>>>>>> problems like that, please reach out to meego-packaging@ and we'll
>>>>>> usually get on it asap.
>>>>>>
>>>>>> (I try to keep track of the monitor but sometimes I don't catch it)
>>>>>>
>>>>>> 2011/6/22 Hofemeier, Ulf <[email protected]>:
>>>>>>> That, plus the fact that qemu in Trunk:Testing seems to be crashing
>>>>>>> reliably for gzip, m4, and db4. I'm working on restoring Trunk at
>>>>>>> least.
>>>>>>> Ulf
>>>>>>>
>>>>>>> On 6/21/11 9:09 PM, "Carsten Munk" <[email protected]> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Something went terribly wrong here:
>>>>>>>>
>>>>>>>> armv8el
>>>>>>>> succeeded: 2
>>>>>>>> failed: 1353
>>>>>>>> unresolvable: 12
>>>>>>>> excluded: 89
>>>>>>>> i586
>>>>>>>> failed: 1440
>>>>>>>> unresolvable: 2
>>>>>>>> excluded: 14
>>>>>>>>
>>>>>>>> /Carsten
>>>>>>>>
>>>>>>>> 2011/6/22 Ulf Hofemeier <[email protected]>:
>>>>>>>>> Hi Chris Ferron,
>>>>>>>>> The following change has been accepted. See the changelog below.
>>>>>>>>> The package util-linux-ng from project Trunk has been deleted.
>>>>>>>>>
>>>>>>>>> Comments:
>>>>>>>>>    Reviewed OK
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> MeeGo Release Engineering Team
>>>>>>>>>
>>>>>>>>> [This message was auto-generated]
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> Request #20594:
>>>>>>>>>
>>>>>>>>>  delete:    Trunk/util-linux-ng
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Message:
>>>>>>>>>    This pacakge will be replaced by the upstream "util-linux"
>>>>>>>>>
>>>>>>>>> State:   accepted     2011-06-21T19:39:10 ulf
>>>>>>>>> Comment: Reviewed OK
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> History: new          2011-06-13T09:56:30 ceferron
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> MeeGo-commits mailing list
>>>>>>>>> [email protected]
>>>>>>>>> http://lists.meego.com/listinfo/meego-commits
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>> _______________________________________________
>> MeeGo-packaging mailing list
>> [email protected]
>> http://lists.meego.com/listinfo/meego-packaging
>
>
_______________________________________________
MeeGo-packaging mailing list
[email protected]
http://lists.meego.com/listinfo/meego-packaging

Reply via email to