Jump to content

Unable to start on Slackware64-14.2


konmit
 Share

Recommended Posts

Hi all!

I've built the latest 0.0.23-alpha on Slackware64-14.2 (multilib) including all deps using SlackBuild scripts.

There's a "disable-root-check.patch" script included in this build but I'm not sure if it's causing this error.

Patch looks like this:

--- a/build/workspaces/update-workspaces.sh
+++ b/build/workspaces/update-workspaces.sh
@@ -1,9 +1,9 @@
 #!/bin/sh
 
-if [ "$(id -u)" = "0" ]; then
-   echo "Running as root will mess up file permissions. Aborting ..." 1>&2
-   exit 1
-fi
+#if [ "$(id -u)" = "0" ]; then
+#   echo "Running as root will mess up file permissions. Aborting ..." 1>&2
+#   exit 1
+#fi
 
 die()
 {

So, this is what the terminal spits out when I try to start the game:

kole@darkstar:/usr/games$ 0ad 
/usr/games/0ad: line 9: 14444 Segmentation fault      "$pyrogenesis" "$@"

Have a look at /usr/games/0ad:

#!/bin/sh

pyrogenesis=$(which pyrogenesis 2> /dev/null)
if [ -x "$pyrogenesis" ] ; then
  "$pyrogenesis" "$@"
else
  echo "Error: pyrogenesis not found in ($PATH)"
  exit 1
fi

Finally, I followed ReportingErrors howto and here's the output:

kole@darkstar:/usr/games$ gdb pyrogenesis 
GNU gdb (GDB) 7.11.1
(...cleared for readability)

Reading symbols from pyrogenesis...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/games/pyrogenesis 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff3febbdb in std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_string(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) () from /usr/lib64/libstdc++.so.6
(gdb) thread apply all bt full

Thread 1 (Thread 0x7ffff7f7eb80 (LWP 14126)):
#0  0x00007ffff3febbdb in std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_string(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) () from /usr/lib64/libstdc++.so.6
No symbol table info available.
#1  0x0000000000640fa9 in ?? ()
No symbol table info available.
#2  0x0000000000672727 in ?? ()
No symbol table info available.
#3  0x00000000006f3447 in ?? ()
No symbol table info available.
#4  0x0000000000432d61 in ?? ()
No symbol table info available.
#5  0x0000000000af3a76 in ?? ()
No symbol table info available.
#6  0x0000000000000000 in ?? ()
No symbol table info available.
  
(gdb) backtrace 
#0  0x00007ffff3febbdb in std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_string(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) () from /usr/lib64/libstdc++.so.6
#1  0x0000000000640fa9 in ?? ()
#2  0x0000000000672727 in ?? ()
#3  0x00000000006f3447 in ?? ()
#4  0x0000000000432d61 in ?? ()
#5  0x0000000000af3a76 in ?? ()
#6  0x0000000000000000 in ?? ()

No debugging symbols found? Is this it or it's something else related to /usr/lib64/libstdc++.so.6? In my case it's a symbolic link to /usr/lib64/libstdc++.so.6.0.21

but I have no idea where to go from here. :(

Also, dependencies of pyrogenesis seem fine, I guess:

kole@darkstar:/usr/games$ ldd pyrogenesis 
	linux-vdso.so.1 (0x00007ffc1edad000)
	libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007fad45c5d000)
	libSDL2-2.0.so.0 => /usr/lib64/libSDL2-2.0.so.0 (0x00007fad458f8000)
	libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007fad456c6000)
	libz.so.1 => /usr/lib64/libz.so.1 (0x00007fad454af000)
	libmozjs38-ps-release.so => /usr/lib64/0ad/libmozjs38-ps-release.so (0x00007fad44d71000)
	libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007fad44a0c000)
	libboost_filesystem.so.1.59.0 => /usr/lib64/libboost_filesystem.so.1.59.0 (0x00007fad447f5000)
	libenet.so.7 => /usr/lib64/libenet.so.7 (0x00007fad445e9000)
	libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x00007fad4436c000)
	libicui18n.so.56 => /usr/lib64/libicui18n.so.56 (0x00007fad43edb000)
	libicuuc.so.56 => /usr/lib64/libicuuc.so.56 (0x00007fad43b43000)
	libsodium.so.23 => /usr/lib64/libsodium.so.23 (0x00007fad438f0000)
	libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007fad435b5000)
	libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00007fad433aa000)
	libopenal.so.1 => /usr/lib64/libopenal.so.1 (0x00007fad43112000)
	libvorbisfile.so.3 => /usr/lib64/libvorbisfile.so.3 (0x00007fad42f09000)
	libnvtt.so => /usr/lib64/0ad/libnvtt.so (0x00007fad42cee000)
	libgloox.so.17 => /usr/lib64/libgloox.so.17 (0x00007fad4299f000)
	libminiupnpc.so.16 => /usr/lib64/libminiupnpc.so.16 (0x00007fad42792000)
	librt.so.1 => /lib64/librt.so.1 (0x00007fad4258a000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fad42386000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fad4200a000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fad41d01000)
	libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007fad41aea000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fad418cd000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fad41504000)
	libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007fad412da000)
	libxcb-dri3.so.0 => /usr/lib64/libxcb-dri3.so.0 (0x00007fad410d8000)
	libxcb-present.so.0 => /usr/lib64/libxcb-present.so.0 (0x00007fad40ed6000)
	libxcb-randr.so.0 => /usr/lib64/libxcb-randr.so.0 (0x00007fad40cca000)
	libxcb-xfixes.so.0 => /usr/lib64/libxcb-xfixes.so.0 (0x00007fad40ac4000)
	libxcb-render.so.0 => /usr/lib64/libxcb-render.so.0 (0x00007fad408bb000)
	libxcb-shape.so.0 => /usr/lib64/libxcb-shape.so.0 (0x00007fad406b8000)
	libxcb-sync.so.1 => /usr/lib64/libxcb-sync.so.1 (0x00007fad404b3000)
	libxshmfence.so.1 => /usr/lib64/libxshmfence.so.1 (0x00007fad402b1000)
	libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00007fad40083000)
	libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007fad3fe81000)
	libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007fad3fc7b000)
	libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00007fad3fa79000)
	libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00007fad3f863000)
	libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00007fad3f65f000)
	libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00007fad3f45a000)
	libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007fad3f248000)
	libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fad3f029000)
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fad3ee26000)
	libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007fad3ec21000)
	libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00007fad3ea13000)
	libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x00007fad3e7c4000)
	libplds4.so => /usr/lib64/libplds4.so (0x00007fad3e5c0000)
	libplc4.so => /usr/lib64/libplc4.so (0x00007fad3e3bb000)
	libnspr4.so => /usr/lib64/libnspr4.so (0x00007fad3e17d000)
	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fad3df58000)
	libboost_system.so.1.59.0 => /usr/lib64/libboost_system.so.1.59.0 (0x00007fad3dd55000)
	libssh2.so.1 => /usr/lib64/libssh2.so.1 (0x00007fad3db28000)
	libssl.so.1 => /lib64/libssl.so.1 (0x00007fad3d8b5000)
	libcrypto.so.1 => /lib64/libcrypto.so.1 (0x00007fad3d462000)
	libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x00007fad3d219000)
	liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007fad3d00b000)
	libicudata.so.56 => /usr/lib64/libicudata.so.56 (0x00007fad3b628000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fad45ec5000)
	libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007fad3b41e000)
	libatomic.so.1 => /usr/lib64/libatomic.so.1 (0x00007fad3b216000)
	libvorbis.so.0 => /usr/lib64/libvorbis.so.0 (0x00007fad3afea000)
	libogg.so.0 => /usr/lib64/libogg.so.0 (0x00007fad3ade4000)
	libnvimage.so => /usr/lib64/0ad/libnvimage.so (0x00007fad3abba000)
	libnvmath.so => /usr/lib64/0ad/libnvmath.so (0x00007fad3a9b1000)
	libnvcore.so => /usr/lib64/0ad/libnvcore.so (0x00007fad3a7a9000)
	libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007fad3a53f000)
	libtiff.so.5 => /usr/lib64/libtiff.so.5 (0x00007fad3a2c8000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fad3a0ad000)
	libidn.so.11 => /usr/lib64/../lib64/libidn.so.11 (0x00007fad39e7a000)
	libgnutls.so.30 => /usr/lib64/../lib64/libgnutls.so.30 (0x00007fad39b0e000)
	libsasl2.so.3 => /usr/lib64/libsasl2.so.3 (0x00007fad398f2000)
	libp11-kit.so.0 => /usr/lib64/../lib64/libp11-kit.so.0 (0x00007fad39690000)
	libunistring.so.0 => /usr/lib64/../lib64/libunistring.so.0 (0x00007fad3937b000)
	libnettle.so.6 => /usr/lib64/../lib64/libnettle.so.6 (0x00007fad39145000)
	libhogweed.so.4 => /usr/lib64/../lib64/libhogweed.so.4 (0x00007fad38f11000)
	libgmp.so.10 => /usr/lib64/../lib64/libgmp.so.10 (0x00007fad38c9b000)
	libffi.so.6 => /usr/lib64/../lib64/libffi.so.6 (0x00007fad38a93000)

Please advise!

Thanks!

  • Like 1
Link to comment
Share on other sites

Hi @konmit It looks like you've been very thorough!

I assigned myself the ticket 4789 a few days ago. I'm not really sure what else to try yet.

I added Slackware build instructions to the documentation. Like you, I did refer to the Slackbuild scripts to get the deps right.

>No debugging symbols found? Is this it or it's something else related to /usr/lib64/libstdc++.so.6? In my case it's a symbolic link to /usr/lib64/libstdc++.so.6.0.21

The reason for that is because the Slackbuild script will strip symbols from the binary, as Slackbuild scripts generally are for packaging releases. If you use the instructions I posted directly above, and build from svn (you could also build from the a23 archive that you already have), the resulting binary will contain debugging symbols.

To be honest, I'm not sure what to try next and I'm hoping that when the 0ad devs have more time they might be able to take a closer look and give me ideas to try. In the meantime, I've asked for help in the Slackware forum at LQ, so you may want to also subscribe to that thread. But I'll try to keep you updated if anything changes for the better. If you have any ideas or more questions, of course, please share them here or on the ticket.

  • Thanks 1
Link to comment
Share on other sites

Thanks for chimin' in @andy5995

Your info is much appreciated.

I've subscribed to LQ thread, hopefully it will gain attention of 'big boys' there. Well, already did, AFAIK. :)

I think I don't understand this:

1 hour ago, andy5995 said:

If you use the instructions I posted directly above, and build from svn (you could also build from the a23 archive that you already have), the resulting binary will contain debugging symbols. 

Did you mean the building order, as you listed, is essential to get the clean build with debugging symbols or one should use svn for that? :unsure:

Thanks!

  • Like 2
Link to comment
Share on other sites

17 minutes ago, konmit said:

Did you mean the building order, as you listed, is essential to get the clean build with debugging symbols or one should use svn for that? :unsure:

Thanks!

I meant the link to the build instructions that I posted above.

The order of building the deps doesn't matter, except that I'm pretty sure that wxGTK3 must be installed before wxPython3 (if you want to build the Atlas Editor). By default, the Slackbuild script won't build the Atlas Editor.

You can have a binary with the debug symbols using either the release archive or the svn. If you want to just use the release archive with the Slackbuild script, I think all you'd have to do is remove the "strip" command from 0ad.Slackbuild.

find $PKG | xargs file | grep -e "executable" -e "shared object" | grep ELF \
  | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null

That section from the Slackbuild script there you could just comment out completely. I think it's the only place where the stripping is done.

Edited by andy5995
  • Thanks 1
Link to comment
Share on other sites

Ok, thank you. I'll try to build it tomorrow and I'll post the results here. :drinks:

Edit Aug. 16

@andy5995

I'm closely watching LQ thread and I'm eager to give it a go once you guys squash that segfaulting bug on stable 14.2. It's just out of my range, plus my regular job keep pushing me away, so I'm not of much help on this. Anyway, fingers crossed! 

Edited by konmit
Typo
Link to comment
Share on other sites

Do you ever try Slackware-current? I tested the patch I mentioned on the LQ thread and it works for me.

As for 14.2, based on the stack trace, I suspect it has something to do with boost library. I tried making a boost package for 14.2 from the -current source, but it failed to build on 14.2.

Link to comment
Share on other sites

I've tried to keep along with -current for couple of months, before 14.2 was released, but I switched to stable for productivity reasons. My system is actually packed with audio production tools from Studioware repo and I'm really picky about what gets in.

Boost lib sounds interesting though. IIRC an app from SW repo was ranting about it and I had to recompile it. I'll check for details, maybe something will come up.

Cheers!

 

Edit: Mon 20 Aug

@andy5995 I couldn't find/remember what was the problem with boost and apparently I didn't recompile it, just reinstalled

the official build. But, here's an interesting thread about official 14.2 boost build problem, that could help in solving this mess.

Best,

K

Edited by konmit
Link to comment
Share on other sites

  • 7 months later...

Hi!

During variable creation, tempCacheFileName is created at VisualReplay.cpp (and also cacheFileName):

static const OsPath tempCacheFileName = VisualReplay::GetDirectoryName() / L"replayCache_temp.json";

which calls GetDirectoryName which uses global variable g_args:

const Paths paths(g_args);

But in main.cpp g_args are filled at function RunGameOrAtlas during runtime, after variable creation:

g_args = args;

Using global g_args early at variable creation while it is not filled yet is causing segmentation fault in Slackware. Don't know why in other distros this won't happen (maybe newer stdlib version... Or different default compiler options... I've tried with g++ 5.3.0).

In previous working version 0.0.21, VisualReplay.cpp uses GetDirectoryName only in runtime. That's why there is no error.

Just moved these at VisualReplay.cpp to inside VisualReplay::ReadCacheFile and VisualReplay::StoreCacheFile and now its working:

static OsPath tempCacheFileName = VisualReplay::GetDirectoryName() / L"replayCache_temp.json";
static OsPath cacheFileName = VisualReplay::GetDirectoryName() / L"replayCache.json";
 

Maybe a better coder could provide a better solution.

This solves https://trac.wildfiregames.com/ticket/4789

Edited by Weber K.
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

5 hours ago, Weber K. said:

Hi!

During variable creation, tempCacheFileName is created at VisualReplay.cpp (and also cacheFileName):

static const OsPath tempCacheFileName = VisualReplay::GetDirectoryName() / L"replayCache_temp.json";

which calls GetDirectoryName which uses global variable g_args:

const Paths paths(g_args);

But in main.cpp g_args are filled at function RunGameOrAtlas during runtime, after variable creation:

g_args = args;

Using global g_args early at variable creation while it is not filled yet is causing segmentation fault in Slackware. Don't know why in other distros this won't happen (maybe newer stdlib version... Or different default compiler options... I've tried with g++ 5.3.0).

In previous working version 0.0.21, VisualReplay.cpp uses GetDirectoryName only in runtime. That's why there is no error.

Just moved these at VisualReplay.cpp to inside VisualReplay::ReadCacheFile and VisualReplay::StoreCacheFile and now its working:

static OsPath tempCacheFileName = VisualReplay::GetDirectoryName() / L"replayCache_temp.json";
static OsPath cacheFileName = VisualReplay::GetDirectoryName() / L"replayCache.json";
 

Maybe a better coder could provide a better solution.

This solves https://trac.wildfiregames.com/ticket/4789

Hey thanks for the fix. Can you submit it on code.wildfiregames.com ? @Itms

  • Like 1
Link to comment
Share on other sites

I am pleased to hear @Weber K. figured out how to get the game running in Slackware 14.2. I am displeased to realize that I do not understand how to implement this solution. Does it require editing a file? If so, which file and where is it? And do I do it before or after compiling? Please forgive my ignorance.

  • Like 1
Link to comment
Share on other sites

Hi, fellows!

 

I am glad to help, and I'm sorry I wasn't that clear...

You have to edit source/ps/GameSetup/VisualReplay.cpp .

You have to 'cut' these 2 lines:

    static OsPath tempCacheFileName = VisualReplay::GetDirectoryName() / L"replayCache_temp.json";
    static OsPath cacheFileName = VisualReplay::GetDirectoryName() / L"replayCache.json";

Then 'paste' them twice... One inside this function:

    bool VisualReplay::ReadCacheFile(const ScriptInterface& scriptInterface, JS::MutableHandleObject cachedReplaysObject)

And another inside this function:

    void VisualReplay::StoreCacheFile(const ScriptInterface& scriptInterface, JS::HandleObject replays)

Paste them just after the opening '{'.

This way we are changing the scope of these variables, the same way they were back at version 0.0.21.

In 0.0.23 they are globals, and are created before the execution, but g_args is still not filled. After these changes, they will be created only upon function call, after g_args was filled.

I've tried to comment at the bug tracker, but I haven't permission. Maybe I will have to become a developer to send a solution.

But maybe @andy5995 could manage this for us?

Please, Andy, may you help us?

Thank you very much!

Edited by Weber K.
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

hi @Weber K., you do not have to be dev to leave comment on trac tickets, just register account there :)

 

And if you want to, you can submit differential on phabricator for review. 

https://code.wildfiregames.com/

 

process of submiting patch for review  is descriped here trac.wildfiregames.com/wiki/Phabricator

 

Have a nice day 

Edited by Angen
  • Like 3
Link to comment
Share on other sites

23 minutes ago, Weber K. said:

Can you create a differential to fix that ? This way we can add inline comments and review the changes more easily 

 

If you are using svn

svn diff -x -U5000 > file.diff

or git 

git diff -U5000  > file.diff

Then upload the file there https://code.wildfiregames.com/differential/diff/create/

  • Like 1
Link to comment
Share on other sites

My solution is more like "Proof of Concept", not a definitive optimized solution, as I am not a very experienced coder.

I prefer to wait for the outcomes from 'audit' first rather than to send an 'ugly' solution, as I believe the coder staff can provide a much better one.

Well... Unless this 'audit' option is not really for real usage... But if this, I think someone will answer that very clear. And then I will post a diff as you pointed out.

I've edited https://code.wildfiregames.com/rP19674 and added that I can send this diff anyway, if ok.

Thanks!

Edited by Weber K.
  • Like 2
Link to comment
Share on other sites

Success! I can now launch the game. I can do single player matches, but if I try to connect to the multiplayer lobby it instantly segfaults.

I am certainly not trying to hijack the thread. Perhaps it is as simple as  I need to those magical two lines into another function?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...