[Bug] In Termux glibc‑runner, attempting to run Wine using box64 caused box64 to crash

[ocnedkf]

In the glibc‑runner environment of Termux, box64 installed via the package‑manager triggers a "buffer overflow detected" error and SIGABRT when running Wine, causing the process to abort. I tried running an Ubuntu container with proot to recompile the latest box64 and modified the ELF interpreter binary, after which the problem disappeared. The only difference in the compilation parameters that could have an effect was that the box32 feature was not enabled.

Would it be possible to add a patch to fix this issue? Thank you！

Other related issues

[ptitSeb]

I have no issue adding a fix to this issue, but I have no idea what to fix for now? The logs in the other ticket is not realy detailled enough and just gives a buffer overflow. At least runs with BOX64_LOG=2 maybe?

Also, having latest box64 v0.4.5 built with box32 would be interesting (I have seen some symbols issue preventing the build it seems, but there is no details, so I cannot really help either)

[ocnedkf]

Alright, I've attached the box64 log collected with BOX64_LOG=2. I will also test and report its behavior when the Box32 feature is enabled at a later time.

[ocnedkf]

box64_log.txt

[ocnedkf]

@ptitSeb I just tried compiling the latest Box64 with Box32 support using proot in an Ubuntu container and in a Termux glibc environment. The build and compilation processes went very smoothly without any errors. The only issue occurred when attempting to install to a specified directory in the Termux glibc environment, where some installation paths were hardcoded under /usr, causing the installation to fail. I resolved this problem by modifying cmake_install.cmake. Additionally, I also tried running the Box64 compiled in Ubuntu within the Termux glibc environment. It did not encounter any issues when running my Wine. I believe this might be because my Wine operates in wow64 mode, which prevented it from exhibiting any issues related to Box32.

[ptitSeb]

@ptitSeb I just tried compiling the latest Box64 with Box32 support using proot in an Ubuntu container and in a Termux glibc environment. The build and compilation processes went very smoothly without any errors. The only issue occurred when attempting to install to a specified directory in the Termux glibc environment, where some installation paths were hardcoded under /usr, causing the installation to fail. I resolved this problem by modifying cmake_install.cmake. Additionally, I also tried running the Box64 compiled in Ubuntu within the Termux glibc environment. It did not encounter any issues when running my Wine. I believe this might be because my Wine operates in wow64 mode, which prevented it from exhibiting any issues related to Box32.

Can you try a simple ctest in build folder, to see if all test work fine? (note that it seems to works fine on the github CI)

[ptitSeb]

box64_log.txt

Crash is inside execv function call (wrapped as my_execv), which is quite complex and and has gone a few fixes and improvments since v0.4.4. So using an updated box64 sources would be key here, I think.

[ocnedkf]

ctest_termux.log
ctest_ubuntu.log
All tests passed in both builds. However, there is one observation: after running ctest multiple times on the Box64 built in Ubuntu, the threadsStart_32bits test may fail occasionally. @ptitSeb

[ocnedkf]

box64_log.txt

Crash is inside execv function call (wrapped as my_execv), which is quite complex and and has gone a few fixes and improvments since v0.4.4. So using an updated box64 sources would be key here, I think.

@Maxython

[ptitSeb]

ctest_termux.log ctest_ubuntu.log All tests passed in both builds. However, there is one observation: after running ctest multiple times on the Box64 built in Ubuntu, the threadsStart_32bits test may fail occasionally. @ptitSeb

Yeah, that's the test itself that could be done better, not a box32 issue.

[ocnedkf]

box64_log.txt

Crash is inside execv function call (wrapped as my_execv), which is quite complex and and has gone a few fixes and improvments since v0.4.4. So using an updated box64 sources would be key here, I think.

@ptitSeb So, I will conduct another test after the official release of box64 v0.4.5 and the subsequent Termux package update. If the original issue still exists, I will provide further feedback. Finally, thank you for your reply.