diffoscope timing out.

[Jan-Benedict Glaw]

On Thu, 2023-11-16 13:56:05 +0000, Chris Lamb <chris at reproducible-builds.org> wrote:
> Holger Levsen wrote:
> 
> > I think there is definitly an UI bug in diffoscope here. If/when diffoscope
> > runs out of memory, it should state that clearly and not throw 42 lines of
> > traceback at the user.
> 
> Good idea. I've added that here:
> 
>   https://salsa.debian.org/reproducible-builds/diffoscope/commit/bb887ddb6e5763b15d4ed9bb448166901dc7253f
> 
> However:
> 
> > Note that because of the underlying memory management architecture
> > (C’s malloc() function), the interpreter may not always be able to
> > completely recover from this situation; it nevertheless raises an
> > exception so that a stack traceback can be printed, in case a
> > run-away program was the cause.
> >
> > — https://docs.python.org/2/library/exceptions.html#exceptions.MemoryError
> 
> ... so this may not work in all situations.

When a program cannot really continue its expected flow, I'm all for a
stackdump and hard-crashing afterwards!

  Such a memory runaway situation should not occur in normal use.
Either track allocations and impose some arbitrary VSZ limit (which
will be wrong for everybody ^^), or just except/abort on failed
allocations. (Esp. with overallocations permitted, an allocation may
actually look like it was successfull, but you'll get signaled to
death once you actually start using that allocation.)

  So... Stack dumps and crashing is quite okay. We don't expect our
parents or grandparents to use it, do we?

MfG, JBG

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20231116/c99a07ae/attachment.sig>