BattleBlock Theater

BattleBlock Theater

Q Dec 30, 2015 @ 9:50am
Linux version not starting
I press start, nothing happens
Linux 3.16.0-57-generic #77~14.04.1-Ubuntu SMP Thu Dec 17 23:20:00 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
< >
Showing 1-15 of 80 comments
Gimmlii Dec 30, 2015 @ 5:36pm 
Same here.
Q Dec 30, 2015 @ 9:52pm 
I forgot to check it after purchase, so now i cant request a refund. Very bad, waste of money...
Q Dec 30, 2015 @ 11:27pm 
ok, i installed libsdl2, which was missing
and now problem is:
This is my LD_LIBRARY_PATH\n
/tools/linux/runtime/i386/lib/i386-linux-gnu:/tools/linux/runtime/i386/lib:/tools/linux/runtime/i386/usr/lib/i386-linux-gnu:/tools/linux/runtime/i386/usr/lib:/usr/lib32:.
End LD_LIBRARY_PATH\n
Setting breakpad minidump AppID = 238460
DEBUG: Steam checks done
BattleBlockTheater: /media/BGBS/BBT_Linux/Core/MemorySystem.cpp:161: void* MemoryBlock::Alloc(unsigned int): Assertion `(!"Got request for zero bytes!")' failed.
Aborted (core dumped)
de.nagical[linux] Sep 21, 2016 @ 9:56am 
Looks like a mesa issue

(gdb) bt full #0 0xf792d818 in __assert_fail () from /lib32/libc.so.6 No symbol table info available. #1 0x082974ec in MemoryBlock::Alloc(unsigned int) () No symbol table info available. #2 0x08270b09 in operator new[](unsigned int) () No symbol table info available. #3 0xecb1bce1 in interstage_cross_validate_uniform_blocks (prog=prog@entry=0x875b6d4, validate_ssbo=validate_ssbo@entry=false) at src/compiler/glsl/linker.cpp:1214 sh = 0x0 sh_num_blocks = <optimized out> sh_blks = <optimized out> i = 0 InterfaceBlockStageIndex = {0x876912c, 0x8768fd4, 0xeae20000 <_nc_waddch_nosync+1632>, 0x85961e0 <s_defaultMemoryBlock>, 0xedd6c700, 0xecb254a1 <lower_discard_flow(exec_list*)+9>} blks = 0x0 num_blks = 0x875b7cc max_num_buffer_blocks = 0

interstage_cross_validate_uniform_blocks(struct gl_shader_program *prog, bool validate_ssbo) { int *InterfaceBlockStageIndex[MESA_SHADER_STAGES]; struct gl_uniform_block *blks = NULL; unsigned *num_blks = validate_ssbo ? &prog->NumShaderStorageBlocks : &prog->NumUniformBlocks; unsigned max_num_buffer_blocks = 0; for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) { if (prog->_LinkedShaders) {
if (validate_ssbo) {
max_num_buffer_blocks +=
prog->_LinkedShaders->NumShaderStorageBlocks;
} else {
max_num_buffer_blocks +=
prog->_LinkedShaders->NumUniformBlocks;
}
}
}

for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) {
struct gl_linked_shader *sh = prog->_LinkedShaders;

InterfaceBlockStageIndex = new int[max_num_buffer_blocks];[/code]


Though, it also seems to be legitimate to call new [0]...
Last edited by de.nagical[linux]; Sep 21, 2016 @ 9:56am
wof. Sep 24, 2016 @ 12:26pm 
Seeing as de.nagical[linux] pointed right to it, I tried recompiled mesa to avoid the new int[0], and now the game starts.

As said, it doesn't look like mesa is doing anything wrong here, just something uncommon that the game's memory allocator (...why) isn't accounting for.
novenary Oct 4, 2016 @ 1:17pm 
I'm a little late to the party, but I just found this thread and decided that modifying mesa for this wasn't a good idea. It's a bug in the game itself.
Anyway after some prodding around in gdb and checking the disassemblies, I found the assert in question and patched it out in the binary.
The fix is easy to apply with a hex editor, simply replace 6 bytes at offset 0x24F2BE with 0x90. This will essentially replace a conditional jump with nops, allowing the function to carry on without giving a damn whether the alloc is zero sized. The game will run just fine this way.
I'm going to let the devs know about it in case they're interested in releasing an update for it.
Last edited by novenary; Oct 4, 2016 @ 1:17pm
Originally posted by Streetwalrus:
I'm a little late to the party, but I just found this thread and decided that modifying mesa for this wasn't a good idea. It's a bug in the game itself.
Anyway after some prodding around in gdb and checking the disassemblies, I found the assert in question and patched it out in the binary.
The fix is easy to apply with a hex editor, simply replace 6 bytes at offset 0x24F2BE with 0x90. This will essentially replace a conditional jump with nops, allowing the function to carry on without giving a damn whether the alloc is zero sized. The game will run just fine this way.
I'm going to let the devs know about it in case they're interested in releasing an update for it.

too bad this fix will break every single time they patch the game. not to mention the average user isn't going to know how to use a hex editor.

they really need to just fix the damn game and stop siloing information behind their support people. these forums exist to allow for information sharing so that people can fix stuff on their own instead of overloading support staff.

for what its worth, I'm on Ubuntu 16.04 with a Radeon R9 390X with the AMDGPU Open Source driver and I'm getting the same issue.

Setting breakpad minidump AppID = 238460
Steam_SetMinidumpSteamID: Caching Steam ID: nnnnnnn [API loaded no]
DEBUG: Steam checks done
BattleBlockTheater: /media/BGBS/BBT_Linux/Core/MemorySystem.cpp:161: void* MemoryBlock::Alloc(unsigned int): Assertion `(!"Got request for zero bytes!")' failed.
Aborted (core dumped)
Last edited by [Hog4n] Panties O'Doom; Nov 13, 2016 @ 7:27pm
[Linux] Ryblade Dec 1, 2016 @ 8:04am 
Streetwalrus, you're a genius! That got it working! Good ol' hexedit. :)

I informed the support staff at Behemoth of this fix since I already had a ticket open with them from earlier. I don't think they'd heard of it yet; they were quite thankful and said they'd pass the info along to the right people, so I assume a patch isn't too far away now. I made sure to give you credit for figuring it out first, of course.

Great work!
Sol Dec 27, 2016 @ 6:37pm 
That some dude disassembling the binary did a better job of solving this than the team behind the game after many months is pretty sad.
yursan9 Dec 29, 2016 @ 3:15pm 
Hope the fix will come soon...
[Linux] Ryblade Jan 11, 2017 @ 4:24am 
Have you guys tried the hexedit? I know the devs haven't officially fixed it yet, but it worked for me and took me less than a minute to fix. This is still a very fun game, so if you haven't played it yet, it's definitely worth a few seconds of manual labour to get it running.

But is it really true that the devs haven't fixed it yet? I notified them over a month ago, and they even replied back to me on it, so that's just laziness on their part if they haven't done anything by now. I still have the emails of my correspondence with the support staff, where I even reminded them it would be smart of them to fix this before the holiday season kicks up, as this was right at the beginning of December.

Geez, what a mess. The fix is so damn easy to apply, too. What a shame.
Last edited by [Linux] Ryblade; Jan 11, 2017 @ 4:26am
fish(y)um\\yum Jan 11, 2017 @ 11:40am 
Mine quit working a long time ago & from what I remember, it was only an issue for people using AMD cards. But I could be remembering wrong, or that was a different issue. Anyone using an NVIDIA card having the same issue?
[Linux] Ryblade Jan 11, 2017 @ 12:12pm 
Certainly not just an AMD issue, I'm using Intel graphics and had this problem.
fish(y)um\\yum Jan 11, 2017 @ 5:35pm 
Originally posted by Ryblade:
Certainly not just an AMD issue, I'm using Intel graphics and had this problem.

Oh ok, thanks for the response. :ss13ok: This issue was well over a year, so I'm not sure if they'll ever fix it. But I sure hope so, it's a great game. :bbtcat:
novenary Jan 13, 2017 @ 10:38am 
The bug is triggered by Mesa, which is the common OpenGL implementation for all open source GPU drivers on Linux.
I've also notified their support team about it, and was told it would be relayed to the right people, but never heard back since then.
< >
Showing 1-15 of 80 comments
Per page: 15 30 50