Unexpected mark stack overflow fatal error in gc

Fatal error in gc unexpected mark stack overflow

It happens randomly on startup of the game (Not loading a save or starting a world) and on accepting and saving changes to a modlist.

Verifying the game or (Sometimes) restarting the PC fixes it, but I am not sure what to blame for it.

Yes I have mods installed but it doesn’t seem consistent.

Is anyone else getting a similar error?

Do you get it everytime?
Also do you have alot of mods or just a few?
And are any 1.3 version?

Cause I have alot and a handful are 1.3, but according to the comments they are working with 1.4 so I don’t think they are causing the overflow.

Just had my first Fatal Error in GC mid-gameplay (modded), just added VGP + Buildable Terrain and a stockpile limit mod to today’s play through about an hour ago or so.
The logs are referencing the usual library mods (Harmony), but also bills and stack limits in the crash stack traces (player log in appdata/user/LocalLow/LudeonStudios/ ..etc). So I’m going to remove the stockpile limit mod and see if it stops; Fingers crossed it’s just a mod derp.

Maybe see if any mods are being referenced in the crash stack trace. A stack trace gives an idea of what was being used at the time of the crash, it’s possible one of them involved could be responsible.

Edit: Haven’t had a re-occurrence of the error so far after disabling the stockpile limit mod.

Источник

Mingw 32bit: Unexpected mark stack overflow (8.0.2+) #260

Hello.
I’m using Gauche on Windows.
Recently, Gauche updated bdwgc to 8.0.2 and build/test error began to occur
on MSYS2/MinGW-w64 32bit environent.
(There is no problem on MSYS2/MinGW-w64 64bit environent.)
(Before update, Gauche used bdwgc 7.6.10 and there was no problem.)

The error message was shown in the message box as follows.
title: ‘Fatal error in GC’
message: ‘Unexpected mark stack overflow’

I tried to investigate this problem and found the following three points.

OS: Windows 8.1 (64bit)
DevTool: MSYS2/MinGW-w64 (32bit) (gcc version 7.3.0 (Rev2, Built by MSYS2 project))

gctest error (this might not be a real problem . )
I downloaded gc-8.0.2.tar.gz and tested it as follows.

Then, I tried to gctest repeatedly as follows.

Then, I tried testA and testB on the following versions and got almost the same results.
(testA was passed and testB had some errors)

• gc master 7bfd248 (2019-1-5)
• gc master e71ab76 (2018-9-5)
• gc master 0846bf2 (2016-11-28) + libatomic_ops-7.6.8.tar.gz
• gc-7.6.10.tar.gz + libatomic_ops-7.6.8.tar.gz
• gc-7.6.8.tar.gz + libatomic_ops-7.6.8.tar.gz
• gc-7.6.8.tar.gz + libatomic_ops-7.6.6.tar.gz
• gc-7.4.16.tar.gz + libatomic_ops-7.4.12.tar.gz

The testB error log in .libs/gctest.gc.log had various patterns as follows.

• ‘List reversal produced incorrect list — collector is broken’
• ‘Wrong finalization data — collector is broken’
• ‘Clobbered a leaf — collector is broken’
• ‘Lost a node at level 3 — collector is broken’
• ‘Lost a node at level 9 — collector is broken’
• ‘Lost a node at level 11 — collector is broken’
• ‘Lost a node at level 13 — collector is broken’

But, old Gauche using bdwgc 7.6.10 was no prolem.
So, I think this might not be a real problem .

‘munmap setting’
I tried ‘git bisect start e71ab76 c7837f8‘ and found the following commit.

• gc master 1aabce0 (2018-4-14) ‘Enable memory unmapping by default’

I confirmed that the error occurs on Gauche since this commit.
So, I added configure option —disable-munmap
and confirmed that no error occurs on this commit.
But, the error still occured on gc-8.0.2.tar.gz .

‘new api for VDB’
I tried ‘git bisect start e71ab76 ad5116f‘ and found the following commit.

• gc master 06009b0 (2018-8-15) ‘New API to turn on manual VDB at runtime’

I confirmed that the error occurs on Gauche since this commit
even though I added configure option —disable-munmap .

For now, I think I should add configure option —disable-munmap
for Windows 32bit environment but I don’t know how to fix 3. .
Also, I can’t use ‘make check’ to judge whether Gauche works normally .

The text was updated successfully, but these errors were encountered:

Источник

Fatal error in gc unexpected mark stack overflow

I’ve been getting this error quite often since the last update (0.7.7f) that states [Fatal Error in GC: Unexpected mark stack overflow];

A little googling brings up plenty of Unity specific links so I assume it’s a Unity error, which this game is built in. I imagine/hope it’ll get fixed soon. Really enjoying the game thus far though.

I’ve been getting this error quite often since the last update;

A little googling brings up plenty of Unity specific links so I assume it’s a Unity error, which this game is built in. I imagine/hope it’ll get fixed soon. Really enjoying the game thus far though.

I have over 150 Hrs in this game an never had that happen

its lighning blast skill
known bug

Damn, that’s my main skill lol. and yeah, coincidentally started after running this sorcerer so that makes a lot of sense. Huh, well back to my Shaman then. Thank you.

EDIT: For others experiencing this issue, you may also want to contribute to this thread on the Last Epoch forums:

Источник

Fatal error in gc unexpected mark stack overflow

RimWorld

Line 5171
«Loaded file (Map) is from version 1.3.3117 rev669, we are running version 1.3.3159 rev754»

Have you changed some mod versions or the Rimworld client version?

All the errors i looked at were all to do with plants, animals or biome. Some for the same items being added twice, do you possibly have 2 versions of the same mod with different version numbers loading at the same time?

I am not a coder, this is my best guess.

I worked tech support for nearly 20 years. You don’t have to be a «programmer» to understand an error message.

Your error says you’re running out of memory. Typically caused by a memory leak, but could also be bad RAM. If you’re getting the error in other applications, check your hardware.

Otherwise, realize that Rimworld was updated a couple days ago and you’re running 500 mods. Something likely broke.

You know how Rimpy works, right? It’s data driven meaning people need to manually put in information so that you can use the database. But this information has to be acquired first. You cannot expect that all this is up to date already. I’m using Rimpy too with 350 mods less and I couldnt start up the game yesterday. It is normal.

No, I’m not a programmer. But I know that «stack overflow» has something to do with memory and memory leaks. It is when some error in the programming leads the program to use up all of the memory which leads to crashes or bluescreens. That can happen in many other programs as well. I had it once in Rimworld and it had to do with textures not being correctly loaded.

Also, by just looking through your modlist. I mean, it looks like you just took everything from the workshop and mashed it together. There are like 5 different storage mods AND stack mods, all the veggie/farming mods put together, like all the builder mods.. literally everything. I’ve used most of these as well but not in a single modlist! There is no way that all that works well together even on a normal day.

Источник

Fatal error in gc unexpected mark stack overflow

I’m on the latest_experimental beta A20.1 (b5) and my friends and I are getting an «unexpected mark stack overflow» crash every now and then. We are using our A20 world.

Has anybody else been getting this? I did not get this crash in any previous versions.

This happened twice in my game (3 players) both yesterday and today. Each time after playing for about 5 hours. We’re not on the experimental branch.

Today, this crash corrupted the save file a bit. When it crashed, I (the host) was a passenger in a 4×4 truck another player was driving. When I restarted the game and the others rejoined, all of the vehicles (and drones) the other players had were located in odd places far away. A crazy thing then happened: I got on my motorcycle to help look for the missing vehicles. Then one of the players joined and my character teleported from my motorcycle into the truck, about a km away! Then my character teleported back onto my motorcycle, but (1) the game opened the console with an error message I didn’t write down, but it was a «null reference» error; and (2) this resulted in my character being stuck on the motorcycle, floating slightly above it in fact, and unable to do anything but mouse-turn. I couldn’t stop it, so I angled it into the corner of a building, and stayed there for a few minutes while the other players tracked down their vehicles and drones. At this point, we decided the safest move was to have everyone pocket their vehicles/drones and logout, me (the host) last of course. I could not exit my motorcycle, but the tab and esc menus worked, so I was able to exit cleanly. Upon reloading the game, tragedy struck, as all of the items in my hotbar had disappeared.

So, as far as I can tell, this bug caused a crash, which led to everything else that happened (which could perhaps be described as other bugs, or just bad luck with the save file getting corrupted by the crash). We are able to continue to play, though it was pretty crushing to lose all of my weapons and tools. Always keep a backup supply of the 2nd best items you’ve found, I guess 🙁

Источник

Comments

Issue #260 (bdwgc).

* mark.c [!NEED_FIXUP_POINTER] (GC_push_all_stack): Call
GC_push_all_eager() instead of GC_push_all() if GC_mark_stack_top is
rather close to GC_mark_stack_limit.

Issue #260 (bdwgc).

* mark.c [!NEED_FIXUP_POINTER] (GC_push_all_stack): Call
GC_push_all_eager() instead of GC_push_all() if GC_mark_stack_top is
rather close to GC_mark_stack_limit.

(a cherry-pick of commit c9381cc from 'release-8_0')

Issue #260 (bdwgc).

* mark.c [!(THREADS && MPROTECT_VDB) && !NEED_FIXUP_POINTER]
(GC_push_all_stack): Call GC_push_all_eager() instead of GC_push_all()
if GC_mark_stack_top is rather close to GC_mark_stack_limit.

(a cherry-pick of commit 420a476 from 'release-7_6')

Issue #260 (bdwgc).

* mark.c [!(THREADS && MPROTECT_VDB)]
(GC_push_all_stack): Call GC_push_all_eager() instead of GC_push_all()
if GC_mark_stack_top is rather close to GC_mark_stack_limit.

(a cherry-pick of commit 420a476 from 'release-7_6')

Issue #260 (bdwgc).

* mark.c [!(THREADS && MPROTECT_VDB)]
(GC_push_all_stack): Call GC_push_all_eager() instead of GC_push_all()
if GC_mark_stack_top is rather close to GC_mark_stack_limit.

This thread is quite old. Please consider starting a new thread rather than reviving this one.