* Pedro Alves:
>> The siginfo_t information should indicate that the signal originated
>> from the kernel.
>
> OOC, where? While a parent process can use "waitid" to get
> a siginfo_t with information about the child exit, that siginfo_t
> is not the same siginfo_t a signal handler would get as
On 11/08/17 02:09, Pedro Alves wrote:
Meanwhile, maybe just having the driver check for SIGKILL and
enumerate likely causes would be better than the status quo.
Pedro Alves
I agree, having some indication it MIGHT be out of memory would stop
people wasting a lot of time, and avoid spurious bu
On 08/10/2017 10:22 PM, Florian Weimer wrote:
> * Andrew Haley:
>
>> On 09/08/17 14:05, Andrew Roberts wrote:
>>> 2) It would be nice to see some sort of out of memory error, rather than
>>> just an ICE.
>>
>> There's nothing we can do: the kernel killed us. We can't emit any
>> message before w
* Andrew Haley:
> On 09/08/17 14:05, Andrew Roberts wrote:
>> 2) It would be nice to see some sort of out of memory error, rather than
>> just an ICE.
>
> There's nothing we can do: the kernel killed us. We can't emit any
> message before we die. (killed) tells you that we were killed, but
> we
On Wed, Aug 9, 2017 at 3:14 PM, Andreas Schwab wrote:
> On Aug 09 2017, Yuri Gribov wrote:
>
>> On Wed, Aug 9, 2017 at 2:49 PM, Andrew Haley wrote:
>>> On 09/08/17 14:05, Andrew Roberts wrote:
2) It would be nice to see some sort of out of memory error, rather than
just an ICE.
>>>
>>>
On 09/08/17 14:05, Andrew Roberts wrote:
> I routinely build the weekly snapshots and RC's, on x64, arm and aarch64.
>
> The last gcc 8 snapshot and the two recent 7.2 RC's have failed to build
> on aarch64 (Raspberry Pi 3, running Arch Linux ARM). I have finally
> traced this to the system runnin
