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.

Sign up for GitHub

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

Jump to bottom

game crashes on first autosave if compiled without lzo but with lzma #6896

Closed
rofl0r opened this issue Sep 8, 2018 · 9 comments
Closed

game crashes on first autosave if compiled without lzo but with lzma #6896

rofl0r opened this issue Sep 8, 2018 · 9 comments
Labels
bug Something isn't working needs triage This issue needs further investigation before it becomes actionable

Comments

@rofl0r
Copy link

rofl0r commented Sep 8, 2018

  • download source of openttd 1.8.0 and openGFX, etc
  • compile on a linux 64bit sys without lzo installed but with xz (liblzma)
  • create a new game with default values
  • wait a minute
  • game crashes (segfault) (probably trying to autosave)
Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 13917]
0x00000000009a65a5 in LZMASaveFilter::WriteLoop (
    this=<error reading variable: Cannot access memory at address 0x7ffff7e228e8>, p=<error reading variable: Cannot access memory at address 0x7ffff7e228e0>, 
    len=<error reading variable: Cannot access memory at address 0x7ffff7e228d8>, 
    action=<error reading variable: Cannot access memory at address 0x7ffff7e228d4>) at /src/build/openttd/openttd-1.8.0/src/saveload/saveload.cpp:2305
2305            void WriteLoop(byte *p, size_t len, lzma_action action)
(gdb) p p
Cannot access memory at address 0x7ffff7e228e0
(gdb)
@rofl0r
Copy link
Author

rofl0r commented Sep 8, 2018 

(gdb) bt
#0  0x00000000009a65a5 in LZMASaveFilter::WriteLoop (
    this=<error reading variable: Cannot access memory at address 0x7ffff7e228e8>, p=<error reading variable: Cannot access memory at address 0x7ffff7e228e0>, 
    len=<error reading variable: Cannot access memory at address 0x7ffff7e228d8>, 
    action=<error reading variable: Cannot access memory at address 0x7ffff7e228d4>) at /src/build/openttd/openttd-1.8.0/src/saveload/saveload.cpp:2305
#1  0x00000000009a66ef in LZMASaveFilter::Write (this=0x2e2bae0, 
    buf=0x2d0b8e0 "GLOG", size=131072)
    at /src/build/openttd/openttd-1.8.0/src/saveload/saveload.cpp:2328
#2  0x00000000009a59e0 in MemoryDumper::Flush (this=0x2d0b8a0, 
    writer=0x2e2bae0)
    at /src/build/openttd/openttd-1.8.0/src/saveload/saveload.cpp:378
#3  0x00000000009a48c2 in SaveFileToDisk (threaded=true)
    at /src/build/openttd/openttd-1.8.0/src/saveload/saveload.cpp:2529
#4  0x00000000009a4983 in SaveFileToDiskThread (arg=0x0)
    at /src/build/openttd/openttd-1.8.0/src/saveload/saveload.cpp:2561
#5  0x0000000000a5d724 in ThreadObject_pthread::ThreadProc (this=0x2e2baa0)
    at /src/build/openttd/openttd-1.8.0/src/thread/thread_pthread.cpp:85
#6  0x0000000000a5d6f8 in ThreadObject_pthread::stThreadProc (thr=0x2e2baa0)
    at /src/build/openttd/openttd-1.8.0/src/thread/thread_pthread.cpp:73
#7  0x00007ffff7dc0620 in start (p=0x7ffff7e42ae8)
    at src/thread/pthread_create.c:150
---Type <return> to continue, or q <return> to quit---
---Type <return> to continue, or q <return> to quit---#8  0x00007ffff7dc250f in __clone () at src/thread/x86_64/clone.s:21
Backtrace stopped: frame did not save the PC

@rofl0r
Copy link
Author

rofl0r commented Sep 9, 2018

while in LZMASaveFilter::Write everything looks OK, the call to LZMASaveFilter::WriteLoop somehow messes up the arguments as if through UB. i suspect the prototype doesn't match the baseclass, or something similar. i changed the last argument to int (as in the gzip class), yet the segfault didn't disappear. GCC 6.4.0

@rofl0r
Copy link
Author

rofl0r commented Sep 9, 2018

i've disabled lzma and enabled zlib. now the same happens with the zlibsavefilter:

Program received signal SIGSEGV, Segmentation fault.
0x00000000009a59fd in ZlibSaveFilter::WriteLoop (
    this=<error reading variable: Cannot access memory at address 0x7fffd33e48e8>, 
    p=<error reading variable: Cannot access memory at address 0x7fffd33e48e0>, 
    len=<error reading variable: Cannot access memory at address 0x7fffd33e48d8>, 
    mode=<error reading variable: Cannot access memory at address 0x7fffd33e48d4>) at /src/build/openttd/openttd-1.8.0/src/saveload/saveload.cpp:2178
2178            void WriteLoop(byte *p, size_t len, int mode)

@andythenorth andythenorth added the needs triage This issue needs further investigation before it becomes actionable label Sep 10, 2018
@andythenorth andythenorth added the stale Stale issues label Jan 5, 2019
@LordAro LordAro removed the stale Stale issues label Jan 23, 2019
@LordAro
Copy link
Member

LordAro commented Jan 23, 2019

I'm unable to reproduce this on Windows/MSYS2 with master, with ./configure --without-liblzo2 and autosaving every month

Could be Linux only...

$ gcc --version
gcc.exe (Rev1, Built by MSYS2 project) 8.2.1 20181214

@LordAro LordAro added the bug Something isn't working label Jan 23, 2019
@PeterN
Copy link
Member

PeterN commented Jan 24, 2019

Cannot reproduce on Linux, compiled with gcc 6.3.0.

@stale
Copy link

stale bot commented Mar 25, 2019

This issue has been automatically marked as stale because it has not had any activity in the last two months.
If you believe the issue is still relevant, please test on the latest nightly and report back.
It will be closed if no further activity occurs within 7 days.
Thank you for your contributions.

@stale stale bot added the stale Stale issues label Mar 25, 2019
@rofl0r
Copy link
Author

rofl0r commented Mar 26, 2019

maybe try with alpine linux. it happened on a musl-libc linux.

Sorry, something went wrong.

@stale stale bot removed the stale Stale issues label Mar 26, 2019
@LordAro
Copy link
Member

LordAro commented Dec 31, 2019

This has been sitting here for a while. Any number of things could be the cause if you're using musl-libc, it's not something that's tested for. Can you debug further yourself? It looks like it could be some memory corruption of some sort - perhaps valgrind will flag something up?

Sorry, something went wrong.

@rofl0r
Copy link
Author

rofl0r commented Jan 1, 2020

i currently don't have time to look into this again. will let you know when it happens again.

Sorry, something went wrong.

@rofl0r rofl0r closed this as completed Jan 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working needs triage This issue needs further investigation before it becomes actionable
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@rofl0r @PeterN @andythenorth @LordAro