> On 19 Nov 2023, at 16:26, Ranjan Maitra via users <users@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > 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? Are you using C extensions in your code? If so I would suspect them for corrupting python. I think you can get into gdb inside the core file with coredumpctl debug. What does “info shared” tell you about what code has been loaded into memory? It is also worth trying to find the type of the object that is being deleted, _PyObject_Free will have pointer to the object. Also not sure where siplib.c is from is it python or an extension? I am assuming here that you are familiar with debugging with gdb. Barry > > Many thanks and best wishes, > Ranjan > > -- > _______________________________________________ > users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
