On 2017-06-30 23:56, Mikulas Patocka wrote:
> Package: libc6
> Severity: important
> Tags: upstream
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
>
> The stack clash patch modifies the kernel so tha
Package: glibc
Version: 2.19-18+deb8u10
By fuzzing my own software using American Fuzzy Lop and its provided
libdislocator (an "abusive allocator" library), I found a code path in
glibc that causes a SIGABRT where it probably shouldn't.
In a low-memory situation, I got the following stack tra
On Wed, Jul 5, 2017 at 9:13 AM, Johannes Schultz wrote:
> mktime is supposed to return -1 and, according to cplusplus.com, has a
> no-throw guarantee for C++ code. So even if some internal memory cannot be
> allocated, I expect mktime to return with an error value and not cause a
> SIGABRT.
> I fo
> None of the internal assertions in tzfile.c have to do with low
> memory, they have to do with logical consistency and expected
> outcomes.
Okay, so let's look at the stack trace again and where it failed.
The failing line 779 in __tzfile_compute is:
if (__tzname[0] == NULL)
{
assert (num_typ
On Wed, Jul 5, 2017 at 1:43 PM, Johannes Schultz wrote:
>
>> None of the internal assertions in tzfile.c have to do with low
>> memory, they have to do with logical consistency and expected
>> outcomes.
>
> Okay, so let's look at the stack trace again and where it failed.
> The failing line 779 in
Am 05.07.2017 um 21:56 schrieb Carlos O'Donell:
I agree.
If you have the opportunity please file a match bug with upstream at
sourceware.org/bugzilla. That way upstream is made aware of the issue.
Sure, I'll report the bug there.
Cheers,
Johannes
(Mail was initially only sent to Carlos, sorry for that :))
> If you have the opportunity please file a match bug with upstream at
> sourceware.org/bugzilla. That way upstream is made aware of the issue.
The bug is now being tracked at:
https://sourceware.org/bugzilla/show_bug.cgi?id=21716
7 matches
Mail list logo
