Descriptive Problem Summary:
Well it happened abruptly even after me holding this version for a few days, now out of no where I get spammed with a message saying BUG: proto mem not large enough whenever I try to boot up my project, causing it massive instability and leading to a crash.
Numbered Steps to Reproduce Problem: - I couldn't say but I do have a screenshot. http://files.byondhome.com/Bustercannon/proto%20mem.PNG
Code Snippet (if applicable) to Reproduce Problem:
Expected Results:
Actual Results:
Does the problem occur:
Every time? Or how often? - All the time now, it likes to occur in my Bleach: Las Noches project, it's been running fine on 447 while compiled in 452, then I updated the linux to 449 and my problem started appearing, due to it not being able to be hosted locally even, it cannot be a linux issue. It SEEMS to of started when I clean compiled.
In other games? - Tried but couldn't reproduce in another project.
When does the problem NOT occur? - Haven't a clue.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.) - See before I would get one message for the imbalance, and everything still ran fine. This was in version 450-451 that it arose for me.
Workarounds: - Tried reducing all of my needed CPU output to see if I could even boot the game and it still spams the message.
ID:79590
 Aug 17 2009, 1:04 pm
|
|||||||||||
Resolved
| |||||||||||
|
Aug 17 2009, 3:18 pm
|
|
Lummox JR
   |
Strangely I can't get this bug to occur. My tests show worlds compiled in 452 are loading with the correct info. However if this is your game, I could give it a shot with compiling your code myself. You can email source to me at [email protected] and I'll see if there's something that I can reproduce on my end.
|
Lummox JR wrote:
Strangely I can't get this bug to occur. My tests show worlds compiled in 452 are loading with the correct info. However if this is your game, I could give it a shot with compiling your code myself. You can email source to me at [email protected] and I'll see if there's something that I can reproduce on my end. Email sent, you should get one from [email protected]. | |
I'm very glad you sent the code because without it this would have definitely been hard to spot. I finally tracked down the problem to a string you have that's longer than 64K. While there is not such a limit on string length, the code that compiles such long text strings into the .dmb is defective. It doesn't appear to have broken in a recent update, which was surprising because there was a "protomem" change made quite recently--rather it seems to have never worked at all. I believe this may have cropped up in other projects as well without being obvious.
As a workaround until the fix is released, you have two options: 1) Shorten the string to under 64K, or 2) Remove the string from the code and load it from a text file that is bundled with the host files for the game. Option 2 is actually the cleaner way to go, but it's a design choice. Anyway, the official bug fix message: Bug fix: Compiling a project containing a string of length 64K or larger created a corrupt .dmb file. | |
Lummox JR wrote:
I'm very glad you sent the code because without it this would have definitely been hard to spot. I finally tracked down the problem to a string you have that's longer than 64K. While there is not such a limit on string length, the code that compiles such long text strings into the .dmb is defective. It doesn't appear to have broken in a recent update, which was surprising because there was a "protomem" change made quite recently--rather it seems to have never worked at all. I believe this may have cropped up in other projects as well without being obvious. I'm gathering it's one of my core procs. Thanks a lot for the help, I'll shorten it. | |
We're still exhibiting this behaviour on 453 Linux. To the best of my knowledge, Chatters has no strings greater than 64K in length in the DMB. SupetAtnx's Decadence is also doing the same, same deployment scenario.
| |
The key question is, what version was it compiled in? If it was still compiled in a version predating 453, there's the problem.
In any case I'm not sure it's appropriate to reopen this bug report since as far as I can tell this bug was actually fixed. New instances would really belong to a separate report since they involve different projects than the original. I'd also need source for the projects in question to be able to determine the cause. | |
In SupetAntx's Decadence case:
world bin v454 min compatibility v437 430 Chatters is: world bin v448 min compatibility v430 430 I'll have SuperAntx create a new report. | |