[issue41335] free(): invalid pointer in list_ass_item() in Python 3.7.3

New submission from Howard A. Landman : I have a program qtd.py that reliably dies with free(): invalid pointer after about 13 hours of runtime (on a RPi3B+). This is hard to debug because (1) try:except: will not catch SIGABRT (2) signal.signal(signal.SIGABRT, sigabrt_handler) also fails to

[issue41335] free(): invalid pointer in list_ass_item() in Python 3.7.3

Change by Howard A. Landman : -- hgrepos: -389 ___ Python tracker <https://bugs.python.org/issue41335> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41335] free(): invalid pointer in list_ass_item() in Python 3.7.3

Howard A. Landman added the comment: This is not a memory leak problem. "Top" reports VIRT 21768 RES 13516 for the whole run, and Python internal resource reporting says 13564 kb for the whole run. So that's less than 1 kb leaked in 118.6M measurement cycles; mo

[issue12423] signal handler doesn't handle SIGABRT from os.abort

Howard A. Landman added the comment: I don't think changing the documentation makes this not be a bug. My situation: I have a Python 3.7.3 program that reliably dies (after about 13 hours, having called its measure() method between 118.6M and 118.7M times) with free(): invalid po

[issue41335] free(): invalid pointer in list_ass_item() in Python 3.7.3

Howard A. Landman added the comment: After a quick glance at the source code for the spidev library, I think it is unlikely but not impossible to be the home for the bug. It does do malloc() and free(), but only for data that is greater than 256 bytes. Short tx and rx data is kept in static

[issue41335] free(): invalid pointer in list_ass_item() in Python 3.7.3

Howard A. Landman added the comment: I'm running under 32-bit Raspbian, so let's assume the magic number is 13. There are only two places in my own code where the number 13 appears: (1) My result_list is 14 items long, i.e. 0 to 13. Relevant code from qtd.py: cum_results = [0, 0,

[issue41335] free(): invalid pointer in list_ass_item() in Python 3.7.3

Howard A. Landman added the comment: Made some progress. By running it under gdb and breaking in malloc_printerr(), I got a better stack trace: Breakpoint 1, malloc_printerr (str=0x76e028f8 "free(): invalid pointer") at malloc.c:5341 5341malloc.c: No such file or directory

[issue41335] free(): invalid pointer in list_ass_item() in Python 3.7.3

Howard A. Landman added the comment: Getting closer to isolating this. A small program that does nothing but call read_regs24() over and over dies with the same error after about 107.4M iterations. So it seems to be definitely in that method. But that only takes a few hours, not half a day

[issue41335] free(): invalid pointer in list_ass_item() in Python 3.7.3

Howard A. Landman added the comment: It appears to be in the spidev library xfer method, when used for reading. Calling that 107.4M times (using the same code as inside my read_regs24() method) causes the free() error. Breakpoint 1, malloc_printerr (str=0x76e028f8 "free(): invalid po

[issue41335] free(): invalid pointer in list_ass_item() in Python 3.7.3

Howard A. Landman added the comment: OK, this has been filed against the spidev library: https://github.com/doceme/py-spidev/issues/107 Do you want it closed, or left open until that gets resolved? -- resolution: -> third party ___ Python trac

[issue41335] free(): invalid pointer in list_ass_item() in Python 3.7.3

Howard A. Landman added the comment: As far as we can tell, this is a known Py_DECREF problem with spidev==3.4. Testing on spidev==3.5 has not triggered the bug so far, so it appears to be already fixed. Under 3.4, changing the list to a tuple did not affect the behavior