wlav / cppyy

Other
405 stars 42 forks source link

corrupted double-linked list #158

Closed shaolei227 closed 10 months ago

shaolei227 commented 1 year ago

Hi Guys,

I am getting following error msg which i have no clue where the issue could be:

The error happens at here: use pdb, it shows the issue happen at: /usr/lib/python3.8/logging/__init__.py(2121)shutdown()

def shutdown(handlerList=_handlerList):
    """
    Perform any cleanup actions in the logging system (e.g. flushing
    buffers).

    Should be called at application exit.
    """
    for wr in reversed(handlerList[:]):

this is the program output: double free or corruption (fasttop) ** Break abort**

0 0x00007f9e99a29c7f in __GI___wait4 (pid=58847, stat_loc=stat_loc

entry=0x7ffc2acafac8, options=options entry=0, usage=usage entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:27

1 0x00007f9e99a29bfb in __GI___waitpid (pid=, stat_loc=stat_loc

entry=0x7ffc2acafac8, options=options entry=0) at waitpid.c:38

2 0x00007f9e99998f67 in do_system (line=) at ../sysdeps/posix/system.c:172

3 0x00007f9e98fd1725 in CppyyLegacy::TUnixSystem::StackTrace() () from /local/mnt/workspace/pySysC_7/pysysc-env/lib/python3.8/site-packages/cppyy_backend/lib/libCoreLegacy.so

4 0x00007f9e94474622 in (anonymous namespace)::do_trace (sig=5) at src/clingwrapper.cxx:239

5 (anonymous namespace)::TExceptionHandlerImp::HandleException (this=, sig=5) at src/clingwrapper.cxx:252

6 0x00007f9e98fd0231 in CppyyLegacy::TUnixSystem::DispatchSignals(CppyyLegacy::ESignals) () from /local/mnt/workspace/pySysC_7/pysysc-env/lib/python3.8/site-packages/cppyy_backend/lib/libCoreLegacy.so

7

8 __GI_raise (sig=sig

entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50

9 0x00007f9e99969859 in __GI_abort () at abort.c:79

10 0x00007f9e999d426e in __libc_message (action=action

entry=do_abort, fmt=fmt entry=0x7f9e99afe298 "%s\n") at ../sysdeps/posix/libc_fatal.c:155

11 0x00007f9e999dc2fc in malloc_printerr (str=str

entry=0x7f9e99b00628 "double free or corruption (fasttop)") at malloc.c:5347

12 0x00007f9e999ddc65 in _int_free (av=0x7f9e99b33b80 , p=0x5b89af0, have_lock=0) at malloc.c:4266

13 0x00007f9e9998d8a7 in run_exit_handlers (status=0, listp=0x7f9e99b33718 <exit_funcs>, run_list_atexit=run_list_atexit

entry=true, run_dtors=run_dtors entry=true) at exit.c:108

14 0x00007f9e9998da60 in __GI_exit (status=) at exit.c:139

15 0x00007f9e9996b08a in __libc_start_main (main=0x4ef1e0
, argc=2, argv=0x7ffc2acb2a88, init=, fini=, rtld_fini=, stack_end=0x7ffc2acb2a78) at ../csu/libc-start.c:342

16 0x00000000005fb39e in _start () at ../Objects/obmalloc.c:1233

wlav commented 1 year ago

Looks like a Python-side proxy is deleted twice. Most likely once on the C++ side, then again later by the interpreter b/c Python believes it owns it. You might get a stack trace through the Python code if you set:

import cppyy.ll
cppyy.ll.set_signals_as_exception(True)

which should then hopefully enable you to find the offending object. Once identified, set the __python_owns__ flag of it to False.

wlav commented 10 months ago

Closing as no updates given for a few months. Feel free to reopen if there is new information.