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

2020-08-04 Thread Howard A. Landman
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

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

2020-08-03 Thread Howard A. Landman
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

2020-08-03 Thread Howard A. Landman
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

2020-08-03 Thread Howard A. Landman
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

2020-08-02 Thread Howard A. Landman
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

2020-07-27 Thread Howard A. Landman
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, 0, 0, 0, 0

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

2020-07-26 Thread Howard A. Landman
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

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

2020-07-22 Thread Howard A. Landman
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 pointer

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

2020-07-22 Thread Howard A. Landman
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; most li

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

2020-07-18 Thread Howard A. Landman
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

2020-07-18 Thread Howard A. Landman
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