We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4769 - [SDL2 2.0.10] free(): invalid pointer / crashes ES after using Retroarch
Summary: [SDL2 2.0.10] free(): invalid pointer / crashes ES after using Retroarch
Status: CLOSED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: 2.0.10
Hardware: ARM Linux
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords: target-2.0.12
Depends on:
Blocks:
 
Reported: 2019-08-20 08:55 UTC by Frank
Modified: 2019-09-20 21:06 UTC (History)
2 users (show)

See Also:


Attachments
fix by Ozkan Sezer (400 bytes, patch)
2019-08-26 13:28 UTC, Frank
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Frank 2019-08-20 08:55:23 UTC
Well when I try to run libretro cores on my RPi3 by using `Retroarch 1.7.7` with `Emulationstation 2.8.4` & `SDL2 2.0.10` then it always crashes once you exit Retroarch. This does not happen with `SDL2 2.0.9` so I'm not exactly sure where I should start to dig :thinking: because it works fine on Generic & Rockchip builds. ES also only crashs when you start lr cores but runs standalone stuff like amiberry fine and returns to the ES frontend as you would expect.

I use a LibreELEC image as base for my builds. https://github.com/5schatten/LibreELEC-RR

I did a bisect & it looks like ES starts to crash after this commit https://github.com/spurious/SDL-mirror/commit/a5a5e2cbd3f3aa2bc1406128fb1b13870a133c5a

**strace output:**
```
writev(2, [{iov_base="free(): invalid pointer", iov_len=23}, {iov_base="\n", iov_len=1}], 2free(): invalid pointer
) = 24
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76ef3000
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
getpid()                                = 3106
gettid()                                = 3106
tgkill(3106, 3106, SIGABRT)             = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=3106, si_uid=0} ---
+++ killed by SIGABRT +++
Aborted
```


**journalctl:**
```
Aug 19 09:58:35 raspi3 emulationstation.start[773]: free(): invalid pointer
Aug 19 09:58:36 raspi3 emulationstation.start[773]: Aborted
```
Comment 1 Frank 2019-08-20 15:59:50 UTC
I also opened an issue for ES https://github.com/RetroPie/EmulationStation/issues/591 since I can't be sure if ES is not faulty.
Comment 2 Sylvain 2019-08-25 14:40:31 UTC
Just a guess, but what about making sure global_cursor is initialized.
eg:

static SDL_Cursor *global_cursor = NULL;

in:

https://hg.libsdl.org/SDL/file/7693573f862d/src/video/raspberry/SDL_rpimouse.c#l54
Comment 3 Frank 2019-08-25 15:13:00 UTC
I tried this patch but unfortunately it still crashs.

--- a/src/video/raspberry/SDL_rpimouse.c
+++ b/src/video/raspberry/SDL_rpimouse.c
@@ -51,7 +51,7 @@
 static void RPI_WarpMouse(SDL_Window * window, int x, int y);
 static int RPI_WarpMouseGlobal(int x, int y);
 
-static SDL_Cursor *global_cursor;
+static SDL_Cursor *global_cursor = NULL;
 
 static SDL_Cursor *
 RPI_CreateDefaultCursor(void)
Comment 4 Ozkan Sezer 2019-08-25 15:55:55 UTC
Looks like a double-free?

Where is free() called, possibly from RPI_FreeCursor()?
If so, RPI_FreeCursor() doesn't set global_cursor to NULL
if cursor==global_cursor, maybe that's the reason.
Comment 5 Ozkan Sezer 2019-08-25 17:42:28 UTC
Try something like the following (untested) :

diff --git a/src/video/raspberry/SDL_rpimouse.c b/src/video/raspberry/SDL_rpimouse.c
--- a/src/video/raspberry/SDL_rpimouse.c
+++ b/src/video/raspberry/SDL_rpimouse.c
@@ -226,6 +226,9 @@ RPI_FreeCursor(SDL_Cursor * cursor)
             SDL_free(cursor->driverdata);
         }
         SDL_free(cursor);
+        if (cursor == global_cursor) {
+            global_cursor = NULL;
+        }
     }
 }
Comment 6 Frank 2019-08-26 13:26:57 UTC
Thx this patch solved the problem for me :-) I guess you'll send this patch upstream?
Comment 7 Frank 2019-08-26 13:28:11 UTC
Created attachment 3932 [details]
fix by Ozkan Sezer
Comment 8 Ozkan Sezer 2019-08-26 15:43:11 UTC
Fix pushed as https://hg.libsdl.org/SDL/rev/5748bf293bea
Comment 9 Ryan C. Gordon 2019-09-20 20:47:40 UTC
We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.
Comment 10 Ryan C. Gordon 2019-09-20 20:48:39 UTC
We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.