On Thu, 2023-11-16 13:56:05 +0000, Chris Lamb <ch...@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 --
signature.asc
Description: PGP signature
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
