Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segmentation fault using self-built version. #3658

Closed
Gnepux opened this issue Jan 5, 2023 · 4 comments
Closed

Segmentation fault using self-built version. #3658

Gnepux opened this issue Jan 5, 2023 · 4 comments

Comments

@Gnepux
Copy link

Gnepux commented Jan 5, 2023

I downloaded the source code, and checkout the tag V1.25. I build following the BUILD document

./install_release.sh
scrcpy

then got the an error as below (build as release version):

scrcpy 1.25 <https://github.com/Genymobile/scrcpy>
Segmentation Fault (core dumped)

after I change the buildtype as debug in install_release.sh, and do again, got the following error log:

scrcpy 1.25 <https://github.com/Genymobile/scrcpy>
scrcpy: ../app/src/util/intr.c:61: sc_intr_set_process: Assertion `intr->socket == SC_SOCKET_NONE' failed.
Abandon (core dumped)

Did I missing some operations ? Thanks a lot !

@rom1v
Copy link
Collaborator

rom1v commented Jan 5, 2023

Thank you for your report.

Could you please build with ASAN enabled and run, as follow:

meson setup x -Db_sanitize=address
ninja -Cx
./run x

That will give the complete stacktrace.

@Gnepux
Copy link
Author

Gnepux commented Jan 5, 2023

Thank you for your reply.

The full stacktrace is:

xupeng@xupeng-OptiPlex-3070:~/work/project/code/github/android/scrcpy$ ./run x
scrcpy 1.25 <https://github.com/Genymobile/scrcpy>
=================================================================
==21827==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000fbf6a0 at pc 0x0000004a78a8 bp 0x7f60548fe9e0 sp 0x7f60548fe9d0
READ of size 4 at 0x000000fbf6a0 thread T1
    #0 0x4a78a7 in sc_intr_set_process ../app/src/util/intr.c:40
    #1 0x479737 in process_check_success_intr ../app/src/adb/adb.c:154
    #2 0x479a30 in sc_adb_start_server ../app/src/adb/adb.c:205
    #3 0x4a46b3 in run_server ../app/src/server.c:691
    #4 0x7f605d749307  (/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0+0x14307)
    #5 0x7f605d789408  (/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0+0x54408)
    #6 0x7f605b5736b9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9)
    #7 0x7f605b2a951c in clone (/lib/x86_64-linux-gnu/libc.so.6+0x10751c)

0x000000fbf6a0 is located 5 bytes to the right of global variable '__PRETTY_FUNCTION__' defined in '../app/src/server.c:138:42' (0xfbf680) of size 27
  '__PRETTY_FUNCTION__' is ascii string 'log_level_to_server_string'
0x000000fbf6a0 is located 32 bytes to the left of global variable '__PRETTY_FUNCTION__' defined in '../app/src/server.c:163:34' (0xfbf6c0) of size 15
  '__PRETTY_FUNCTION__' is ascii string 'execute_server'
SUMMARY: AddressSanitizer: global-buffer-overflow ../app/src/util/intr.c:40 sc_intr_set_process
Shadow bytes around the buggy address:
  0x0000801efe80: f9 f9 f9 f9 00 00 00 01 f9 f9 f9 f9 00 00 03 f9
  0x0000801efe90: f9 f9 f9 f9 00 07 f9 f9 f9 f9 f9 f9 00 00 02 f9
  0x0000801efea0: f9 f9 f9 f9 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9
  0x0000801efeb0: 00 00 06 f9 f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9
  0x0000801efec0: 00 00 00 07 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9
=>0x0000801efed0: 00 00 00 03[f9]f9 f9 f9 00 07 f9 f9 f9 f9 f9 f9
  0x0000801efee0: 00 07 f9 f9 f9 f9 f9 f9 00 07 f9 f9 f9 f9 f9 f9
  0x0000801efef0: 00 00 05 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9
  0x0000801eff00: 00 00 00 02 f9 f9 f9 f9 00 00 00 00 00 f9 f9 f9
  0x0000801eff10: f9 f9 f9 f9 00 03 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
  0x0000801eff20: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
Thread T1 created by T0 here:
    #0 0x7f605da04253 in pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x36253)
    #1 0x7f605d789459  (/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0+0x54459)

==21827==ABORTING

By the way, my computer configuration is:

Ubuntu 16.04 LTS 64bit
Mem: 16G
CPU: Intel Core i5

and the version I download using snap install works fine.

Thank you!

@rom1v
Copy link
Collaborator

rom1v commented Jan 5, 2023

#4 0x7f605d749307 (/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0+0x14307)

For some reason, during execution it uses SDL 1.2 (but you compiled against SDL 2, otherwise meson would have failed).

In SDL 1.2, the signature of SDL_CreateThread() (used by sc_thread_create(), which runs run_server()) was:

SDL_Thread *SDL_CreateThread(int (*fn)(void *), void *data)

In SDL 2.x, the signature is:

SDL_CreateThread(int(SDLCALL *fn)(void *), const char *name, void *data)

Therefore, in the end, what is called by the caller is SDL_CreateThread(run_server, "scrcpy-server", server), but SDL 1.2 interprets the string "scrcpy-server" as the userdata, which is cast to struct sc_server *). This explains why the segfault access is at static string locations:

0x000000fbf6a0 is located 5 bytes to the right of global variable '__PRETTY_FUNCTION__' defined in '../app/src/server.c:138:42' (0xfbf680) of size 27
  '__PRETTY_FUNCTION__' is ascii string 'log_level_to_server_string'
0x000000fbf6a0 is located 32 bytes to the left of global variable '__PRETTY_FUNCTION__' defined in '../app/src/server.c:163:34' (0xfbf6c0) of size 15
  '__PRETTY_FUNCTION__' is ascii string 'execute_server'

So TL;DR: the problem is that it is run against SDL 1.2 (check the output of scrcpy -v).

@Gnepux
Copy link
Author

Gnepux commented Jan 6, 2023

Indeed, my computer install both of SDL1.2 and SDL2 at same time. Maybe this line dependency('sdl2', version: '>= 2.0.5') in meason script find the SDL2 and pass, but linked libSDL.so at compile time. The libSDL.so is actually version 1.2.

Now I remove SDL 1.2 in my computer, the problem solved.

Thank you for your help !

@Gnepux Gnepux closed this as completed Jan 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants