This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: dlopen() error with no error message from dlerror()
Type: crash Stage: resolved
Components: ctypes Versions: Python 3.5
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: eryksun, shuoz, terry.reedy
Priority: normal Keywords:

Created on 2018-09-29 06:38 by shuoz, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (3)
msg326668 - (view) Author: shuoz (shuoz) Date: 2018-09-29 06:38
python _ctypes.dlclose(arg). 
Never check the arg  so we get a Segmentation fault (core dumped)

poc.py
```
import _ctypes
_ctypes.dlclose(3)  # 3-4294967296
```
python poc.py


gdb info

```
----------------------------------registers-----------------------------------]
RAX: 0x7ffff7ffcca0 --> 0x40d0d00000000 
RBX: 0x0 
RCX: 0x7ffff6a49fd0 (<dlclose_doit>:	mov    rax,QWORD PTR [rip+0x201fe1]        # 0x7ffff6c4bfb8)
RDX: 0x2e10a0bf96213a9d 
RSI: 0x0 
RDI: 0x3 
RBP: 0x7ffff6a49fd0 (<dlclose_doit>:	mov    rax,QWORD PTR [rip+0x201fe1]        # 0x7ffff6c4bfb8)
RSP: 0x7fffffffd280 --> 0x0 
RIP: 0x7ffff7dee161 (<_dl_close+1>:	test   BYTE PTR [rdi+0x3d4],0x8)
R8 : 0x3 
R9 : 0x7ffff6a49fd0 (<dlclose_doit>:	mov    rax,QWORD PTR [rip+0x201fe1]        # 0x7ffff6c4bfb8)
R10: 0xc55dc0 --> 0x31 ('1')
R11: 0x7ffff7eec3d8 --> 0x9 ('\t')
R12: 0x3 
R13: 0x7ffff7e952b0 --> 0x1 
R14: 0x7ffff2d12140 (<py_dl_close>:	push   r14)
R15: 0x7ffff7e17228 --> 0x16
EFLAGS: 0x10246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x7ffff7dee152:	nop    DWORD PTR [rax+0x0]
   0x7ffff7dee156:	nop    WORD PTR cs:[rax+rax*1+0x0]
   0x7ffff7dee160 <_dl_close>:	push   rbx
=> 0x7ffff7dee161 <_dl_close+1>:	test   BYTE PTR [rdi+0x3d4],0x8
   0x7ffff7dee168 <_dl_close+8>:	mov    rbx,rdi
   0x7ffff7dee16b <_dl_close+11>:	jne    0x7ffff7dee210 <_dl_close+176>
   0x7ffff7dee171 <_dl_close+17>:	mov    edx,DWORD PTR [rdi+0x310]
   0x7ffff7dee177 <_dl_close+23>:	test   edx,edx
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd280 --> 0x0 
0008| 0x7fffffffd288 --> 0x7ffff7de7564 (<_dl_catch_error+116>:	mov    rax,QWORD PTR [rsp+0x8])
0016| 0x7fffffffd290 --> 0x0 
0024| 0x7fffffffd298 --> 0x7ffff7fd8720 --> 0x7fffffffd2e0 --> 0x7ffff737f690 --> 0x0 
0032| 0x7fffffffd2a0 --> 0x0 
0040| 0x7fffffffd2a8 --> 0x7ffff737f690 --> 0x0 
0048| 0x7fffffffd2b0 --> 0x7ffff737f698 --> 0x0 
0056| 0x7fffffffd2b8 --> 0x7ffff737f688 --> 0x0 
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
_dl_close (_map=0x3) at dl-close.c:809
809	dl-close.c: No such file or directory.
gdb-peda$ bt
```
msg327174 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2018-10-05 19:00
FWIW, the method does not exist on Windows

>>> _ctypes.dlclose(3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module '_ctypes' has no attribute 'dlclose'
msg327213 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2018-10-06 02:55
> FWIW, the method does not exist on Windows

In Windows it's FreeLibrary, for which the implementation in NT calls loader and runtime library functions such as LdrUnloadDll and RtlImageNtHeaderEx. These OS functions internally use structured exception handling (SEH) to retun status codes such as STATUS_DLL_NOT_FOUND and STATUS_INVALID_IMAGE_FORMAT instead of crashing the process when passed an invalid module handle (i.e. module base address).

For POSIX, I don't see what can be done to avoid a crash when dlclose is passed a bad handle (i.e. module address). We can check for NULL, the obvious case, but otherwise AFAIK we can only detect an invalid address by trying to access it, which triggers a segfault. This is the reason that dlclose is only available in the private _ctypes module, and ctypes itself never even calls it.
History
Date User Action Args
2022-04-11 14:59:06adminsetgithub: 79021
2021-03-13 04:15:27eryksunsetstatus: open -> closed
resolution: not a bug
stage: resolved
2018-10-06 02:55:41eryksunsetnosy: + eryksun
messages: + msg327213
2018-10-05 19:00:35terry.reedysetnosy: + terry.reedy
messages: + msg327174
2018-09-29 06:38:06shuozcreate