Linux version not starting

[kmoxville]

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

[Gimmlii]

Same here.

[kmoxville]

I forgot to check it after purchase, so now i cant request a refund. Very bad, waste of money...

[kmoxville]

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]]

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]...

[wof.]

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]

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.

[[Hog4n] Panties O'Doom]

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)

[Ryblade]

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]

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]

Hope the fix will come soon...

[Ryblade]

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.

[β‘αττεrγ ϝlαͼͽ¡d [π]]

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?

[Ryblade]

Certainly not just an AMD issue, I'm using Intel graphics and had this problem.

[β‘αττεrγ ϝlαͼͽ¡d [π]]

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. 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.

[novenary]

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.