Hi, I was running the code here: https://github.com/maitra/Visual-Information-Fidelity---Python3
However, the code runs in F38 (python 3.11) without error, but not in F39 (python 3.12) where it ends with a segmentation fault (after doing the calculations). Both, however, give an answer that are not the same after the 14th decimal place. Not sure if I should be bothered about that. Looking at valgrind, I can not tell if there is an error in the python call itself. Here is what I get (note that the code calls shared objects created by the gcc compiler). ==278781== Invalid read of size 8 ==278781== at 0x4A50B5B: UnknownInlinedFun (pycore_pystate.h:118) ==278781== by 0x4A50B5B: UnknownInlinedFun (obmalloc.c:866) ==278781== by 0x4A50B5B: _PyObject_Free (obmalloc.c:1850) ==278781== by 0x6526E92E: UnknownInlinedFun (siplib.c:2241) ==278781== by 0x6526E92E: UnknownInlinedFun (objmap.c:69) ==278781== by 0x6526E92E: finalise (siplib.c:2143) ==278781== by 0x49AC4D3: UnknownInlinedFun (pylifecycle.c:3018) ==278781== by 0x49AC4D3: Py_FinalizeEx.cold (pylifecycle.c:1977) ==278781== by 0x4B22336: Py_RunMain (main.c:691) ==278781== by 0x4ADD85B: Py_BytesMain (main.c:743) ==278781== by 0x4EE1149: (below main) (libc_start_call_main.h:58) ==278781== Address 0x10 is not stack'd, malloc'd or (recently) free'd ==278781== ==278781== ==278781== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==278781== Access not within mapped region at address 0x10 ==278781== at 0x4A50B5B: UnknownInlinedFun (pycore_pystate.h:118) ==278781== by 0x4A50B5B: UnknownInlinedFun (obmalloc.c:866) ==278781== by 0x4A50B5B: _PyObject_Free (obmalloc.c:1850) ==278781== by 0x6526E92E: finalise (siplib.c:2143) ==278781== by 0x49AC4D3: UnknownInlinedFun (pylifecycle.c:3018) ==278781== by 0x49AC4D3: Py_FinalizeEx.cold (pylifecycle.c:1977) ==278781== by 0x4B22336: Py_RunMain (main.c:691) ==278781== by 0x4ADD85B: Py_BytesMain (main.c:743) ==278781== by 0x4EE1149: (below main) (libc_start_call_main.h:58) ==278781== If you believe this happened as a result of a stack ==278781== overflow in your program's main thread (unlikely but ==278781== possible), you can try to increase the size of the ==278781== main thread stack using the --main-stacksize= flag. ==278781== The main thread stack size used in this run was 8388608. ==278781== ==278781== HEAP SUMMARY: ==278781== in use at exit: 18,046,811 bytes in 92,137 blocks ==278781== total heap usage: 2,212,074 allocs, 2,119,937 frees, 1,983,813,202 bytes allocated ==278781== ==278781== LEAK SUMMARY: ==278781== definitely lost: 2,160,027 bytes in 41,915 blocks ==278781== indirectly lost: 112 bytes in 2 blocks ==278781== possibly lost: 5,021,632 bytes in 34,430 blocks ==278781== still reachable: 10,863,024 bytes in 15,769 blocks ==278781== suppressed: 0 bytes in 0 blocks It is possible that there is a bug in the code itself, but nothing above points to my created code. Any suggestions? Or is this a bug? Many thanks and best wishes, Ranjan -- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
