Hi Diego, Le mercredi 13 octobre 2021 à 07:56 +0200, difa.csi a écrit : > Following quite a bit of debugging, I think I've found a wrong check in > memory.c file, at line 2789 (0.3.13+ds-3): > https://sources.debian.org/src/openblas/0.3.13+ds-3/driver/others/memory.c/ > > IIUC, it should check *func != NULL instead of func != NULL . func > should be "guaranteed" to not be NULL since memoryalloc is defined at > line 2641. > > Else, when it reaches the last element of memoryalloc[], func is not > NULL but *func is, and it's what gets dereferenced. > > I noticed it because both octave and python-numpy started segfaulting > after a distro upgrade. > In both cases the stack trace contained something like: > #0 0x0000000000000000 in ?? () > #1 0x00007f9c614de7d9 in ?? () from > /usr/lib/x86_64-linux-gnu/libopenblas.so.0 > > and valgrind trace: > ==746909== Jump to the invalid address stated on the next line > ==746909== at 0x0: ??? > ==746909== by 0xBDFD708: blas_memory_alloc (memory.c:2793) > ==746909== by 0xBDFDF03: blas_thread_server (blas_server.c:366) > ==746909== by 0x8D33EA6: start_thread (pthread_create.c:477) > ==746909== by 0x725EDEE: clone (clone.S:95) > ==746909== Address 0x0 is not stack'd, malloc'd or (recently) free'd > > Strangely, the segfaults disappeared installing libopenblas0-serial.
I guess you did that debugging in relation to #995450. I suggest that you communicate your above analysis directly to upstream, by opening an issue at: https://github.com/xianyi/OpenBLAS/issues/new The upstream developers are in the best position to give you feedback and to decide whether or not to apply your suggested patch. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ https://www.debian.org
signature.asc
Description: This is a digitally signed message part
-- debian-science-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
