Handle leak in SDL_kmsdrmmouse.c

SDL Development
1

SDL_kmsdrmmouse.c uses KMSDRM_gbm_device_get_fd() in two functions. The handle is not closed in any of those 2 places. This causes handle leak at least on some platforms.

Does anybody know - is KMSDRM_gbm_device_get_fd() supposed to return a new handle (e.g. duplicate of the existing handle) that needs to be closed? Or is it supposed to return the existing handle?

2

it’s an existing handle:

3

Thank you! I have found this source code, however at least in some platforms subsequent calls to KMSDRM_gbm_device_get_fd() return different handle values.

I have built release-2.0.16 with this patch and obtained this output in the log when running the application:

ERROR: DEBUG2 Handle is 30
ERROR: DEBUG2 Handle is 31
ERROR: DEBUG2 Handle is 32
ERROR: DEBUG2 Handle is 32
ERROR: DEBUG2 Handle is 33
ERROR: DEBUG2 Handle is 34

P.S. The application is EmulationStation running on Batocera Linux on ODROID-GO Advance Black Edition game console.

4

That’s weird - maybe you (or your version of SDL, libgbm or whatever) have some sort of memory corruption that overrides that value? You could try breaking in a debugger after the first print and add a data watchpoint on gbm->fd (or gbm->v0.fd) and see what changes it.

BTW, seems like libgbm is part of Mesa and the current code can be found at src/gbm/main/gbm.c · main · Mesa / mesa · GitLab - this looks slightly different, but basically it still just returns a field of the gbm_device struct.
Also, the official kmscube demo source (drm-common.c · master · Mesa / kmscube · GitLab) uses gbm_device_get_fd() without closing the fd.

5

Unfortunately there doesn’t seem to be memory corruption, but Mali (possibly Rockchip) specific implementation:

(gdb) disassemble/rs 0x7f7ec929bc
Dump of assembler code for function gbm_device_get_fd:
   0x0000007f7ec929bc <+0>:     a0 00 00 b4     cbz     x0, 0x7f7ec929d0 <gbm_device_get_fd+20>
   0x0000007f7ec929c0 <+4>:     00 00 40 b9     ldr     w0, [x0]
   0x0000007f7ec929c4 <+8>:     02 00 80 52     mov     w2, #0x0                        // #0
   0x0000007f7ec929c8 <+12>:    c1 80 80 52     mov     w1, #0x406                      // #1030
   0x0000007f7ec929cc <+16>:    31 21 f0 17     b       0x7f7e89ae90 <fcntl@plt>
   0x0000007f7ec929d0 <+20>:    00 00 80 12     mov     w0, #0xffffffff                 // #-1
   0x0000007f7ec929d4 <+24>:    c0 03 5f d6     ret
End of assembler dump.
(gdb) info sym 0x7f7ec929bc
gbm_device_get_fd in section .text of /usr/lib64/libmali.so.1
(gdb)

Looks like this implementation of gbm_device_get_fd() actually calls fcntl() with 1030 what appears to be F_DUPFD_CLOEXEC.

1 Like
6

Try to find out what exact version of libgdm your distro ships and if they have any custom patches on it etc

7

Thank you! The PR #5049 in libsdl-org/SDL with the proposed fix has already been accepted. This issue should be fixed in next version of libSDL.