https://sourceware.org/bugzilla/show_bug.cgi?id=32713
--- Comment #4 from Brian Mak ---
(In reply to Mark Wielaard from comment #2)
> See also this kernel thread:
> https://lore.kernel.org/all/39fc2866-dff3-43c9-9d40-e8ff30a21...@juniper.net/
> Looks like the kernel people believe this in "in spe
A new failure has been detected on builder elfutils-fedora-s390x while building
elfutils.
Full details are available at:
https://builder.sourceware.org/buildbot/#/builders/43/builds/395
Build state: failed test (failure)
Revision: e543c7f5c2b28ac2bce1e9f09fad30caebb579d5
Worker: fedora-s390x
A new failure has been detected on builder elfutils-snapshots-coverage while
building elfutils.
Full details are available at:
https://builder.sourceware.org/buildbot/#/builders/250/builds/210
Build state: failed test (failure)
Revision: e543c7f5c2b28ac2bce1e9f09fad30caebb579d5
Worker: snaps
https://sourceware.org/bugzilla/show_bug.cgi?id=32318
Frank Ch. Eigler changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi -
> [...]
> This does sounds like a bug in glibc sscanf. I cannot find a
> description of what exactly happens with 'm' modifier allocated
> buffers on error. So I can imagine a double free if sscanf frees the
> buffer on error. But returning a bogus pointer? That seems a bug. If
> we aren't gu
https://sourceware.org/bugzilla/show_bug.cgi?id=32673
xuantong shi changed:
What|Removed |Added
CC||sxt1001 at outlook dot com
--- Comment
