Skip to content

SegFault before Python shutdown #1683

Closed

Description

@AndyWatterman

Environment

  • Pythonnet version: 3.0.0.dev1
  • Python version: 3.9.9
  • Operating System: Kali Linux
  • .NET Runtime:
    mono-complete:amd64/kali-rolling 6.8.0.105+dfsg-3.2 uptodate
    mono-devel:all/kali-rolling 6.8.0.105+dfsg-3.2

Details

This example causes segfault before python shutdown:

import clr
from System import IntPtr
a = clr.GetClrType(IntPtr)

Actually no matter what type is imported (IntPtr, Console, etc.) - crashing anyway. However, crash happen exactly after the program finished its executing and only when NO debugging.

gef➤  bt

#0  0x0000000040071c50 in ?? ()
#1  0x0000000000508a13 in _Py_Dealloc (op=<optimized out>) at ../Objects/object.c:2209
#2  _Py_DECREF (op=<optimized out>) at ../Include/object.h:430
#3  _Py_XDECREF (op=<optimized out>) at ../Include/object.h:497
#4  free_keys_object (keys=0x11ac070) at ../Objects/dictobject.c:598
#5  0x0000000000508824 in dictkeys_decref (dk=<optimized out>) at ../Objects/dictobject.c:333
#6  dict_dealloc (mp=0x7ffff78671c0) at ../Objects/dictobject.c:2026
#7  0x00000000005a9f60 in _Py_DECREF (op=<optimized out>) at ../Include/object.h:430
#8  _Py_XDECREF (op=<optimized out>) at ../Include/object.h:497
#9  module_dealloc (m=0x7ffff7863cc0) at ../Objects/moduleobject.c:677
#10 0x00000000004f9749 in _Py_Dealloc (op=<optimized out>) at ../Objects/object.c:2209
#11 _Py_DECREF (op=<optimized out>) at ../Include/object.h:430
#12 _Py_XDECREF (op=<optimized out>) at ../Include/object.h:497
#13 insertdict (mp=<optimized out>, key='__main__', hash=<optimized out>, value=<optimized out>) at ../Objects/dictobject.c:1123
#14 0x00000000006294a0 in _PyImport_Cleanup (tstate=0x94e6e0) at ../Python/import.c:526
#15 0x000000000062732f in Py_FinalizeEx () at ../Python/pylifecycle.c:1426
#16 0x000000000061e0c0 in Py_RunMain () at ../Modules/main.c:679
#17 0x0000000000606199 in Py_BytesMain (argc=<optimized out>, argv=<optimized out>) at ../Modules/main.c:731
#18 0x00007ffff7c427ed in __libc_start_main (main=0x606160 <main>, argc=0x2, argv=0x7fffffffde18, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffde08) at ../csu/libc-start.c:332
#19 0x000000000060609a in _start ()

gef➤  xinfo 0x0000000040071c50
[*] Cannot reach 0x40071c50 in memory space

gef➤  xinfo 0x0000000000508a13
Page: 0x000000000041f000  →  0x0000000000690000 (size=0x271000)
Permissions: r-x
Pathname: /usr/bin/python3.9
Offset (from page): 0xe9a13
Inode: 6816263
Segment: .text (0x0000000000420e70-0x000000000068fe11)
Offset (from segment): 0xe7ba3
Symbol: free_keys_object.lto_priv+115

If we add at the end of the script this line, then everything works like a charm:

Environment.Exit(0)

Also works well if we clear variable at the end:

a = None

Activity

  1. filmor commented on Jan 28, 2022

    @filmor
    Member

    I can confirm this issue. After playing around a bit, I found out that this occurs only if the System.RuntimeType instance that comes back from GetClrType is bound until the end of the program. So the following are not segfaulting:

    import clr
    from System import IntPtr
    a = clr.GetClrType(IntPtr)
    a = 1

    and

    import clr
    from System import IntPtr
    clr.GetClrType(IntPtr)
  2. MikeFrampton commented on Feb 14, 2022

    @MikeFrampton

    Confirm this issue happening for me too on Ubuntu 21.10.

    Python version: 3.9.7.
    Pythonnet version: 3.0.0a2

    I'm not using virtual environment, though if I set my imported dotnet class to None, the issue goes away. I hope I'm not just shadowing a resource leak here or something.

  3. added this to the 3.0.0 milestone on Feb 17, 2022
  4. lostmsu commented on Feb 28, 2022

    @lostmsu
    Member

    @filmor I believe this issue happens because clr_loader forces Mono shutdown before Python shuts down. While it might make sense if you want to restart the runtime in the same process, I don't think Mono supports that scenario and neither should we.

    We could hack around it with slots holder stuff, but personally I think this is an overcomplication.

    The same probably applies to the other runtimes as well.

  5. lostmsu commented on Mar 3, 2022

    @lostmsu
    Member
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions