java.lang.Error on BTraceRuntime.recordExit

[hsyyid]

After testing extensively, I was able to produce the following exception. I am not sure how this error is happening, and furthermore it appears that the try catch block that should catch an exception like this was never called.

This error is especially odd because BTraceRuntime#recordExit shouldn't cause any issues as far as I can see.. https://github.com/hsyyid/btrace/blob/79e00d142437f4e435600851c60d5ef63dafd904/src/share/classes/com/sun/btrace/BTraceRuntime.java#L1947

The code that it appears to be injected into is https://github.com/SpongePowered/SpongeCommon/blob/eb4dbb5e5c85306c7bd50421a7419f03b8bec15f/src/main/java/org/spongepowered/common/util/gen/AbstractBlockBuffer.java#L55

Unsure if that has any effect.

Any insight on why this is happening and how to prevent it would be very useful.

(Also, no I am not able to reproduce this consistently, although I can try to see if I can)

Thanks!

Stacktrace:

java.lang.Error
	at com.sun.btrace.BTraceRuntime.recordExit(BTraceRuntime.java:1948)
	at com.sun.btrace.BTraceUtils$Profiling.recordExit(BTraceUtils.java:5149)
	at org.spongepowered.common.util.gen.AbstractBlockBuffer.$btrace$com$negafinity$btrace$Logger$exit(AbstractBlockBuffer.java)
	at org.spongepowered.common.util.gen.AbstractBlockBuffer.checkRange(AbstractBlockBuffer.java:59)
	at org.spongepowered.common.util.gen.ChunkPrimerBuffer.setBlock(ChunkPrimerBuffer.java:81)
	at net.minecraft.world.gen.ChunkProviderOverworld.setBedrock(ChunkProviderOverworld.java:815)
	at net.minecraft.world.gen.ChunkProviderOverworld.populate(ChunkProviderOverworld.java:803)
	at org.spongepowered.common.world.gen.SpongeChunkGenerator.func_185932_a(SpongeChunkGenerator.java:243)
	at net.minecraft.world.gen.ChunkProviderServer.func_186025_d(ChunkProviderServer.java:140)
	at net.minecraft.world.World.func_72964_e(World.java:303)
	at net.minecraft.world.World.func_175726_f(World.java:298)
	at net.minecraft.world.WorldServer.func_180495_p(WorldServer.java:3104)
	at net.minecraft.world.World.getBlock(World.java:4866)
	at org.spongepowered.api.world.extent.BlockVolume.getBlock(BlockVolume.java:97)
	at org.spongepowered.api.world.Location.getBlock(Location.java:513)
	at org.spongepowered.common.data.property.store.common.AbstractBlockPropertyStore.getFor(AbstractBlockPropertyStore.java:98)
	at org.spongepowered.common.data.property.PropertyStoreDelegate.getFor(PropertyStoreDelegate.java:59)
	at net.minecraft.world.World.getProperty(World.java:6337)
	at org.spongepowered.api.data.property.LocationBasePropertyHolder.getProperty(LocationBasePropertyHolder.java:52)
	at org.spongepowered.api.util.blockray.BlockRay.advanceOneBlock(BlockRay.java:333)
	at org.spongepowered.api.util.blockray.BlockRay.advance(BlockRay.java:268)
	at org.spongepowered.api.util.blockray.BlockRay.hasNext(BlockRay.java:232)
	at org.spongepowered.api.util.blockray.BlockRay.end(BlockRay.java:260)
	at io.github.nucleuspowered.nucleus.modules.rtp.commands.RandomTeleportCommand$RTPTask.accept(RandomTeleportCommand.java:231)
	at io.github.nucleuspowered.nucleus.modules.rtp.commands.RandomTeleportCommand$RTPTask.accept(RandomTeleportCommand.java:145)
	at org.spongepowered.common.scheduler.SchedulerBase.lambda$startTask$0(SchedulerBase.java:183)
	at org.spongepowered.common.scheduler.SchedulerBase$$Lambda$244/1173213045.run(Unknown Source)
	at org.spongepowered.common.scheduler.SyncScheduler.executeTaskRunnable(SyncScheduler.java:81)
	at org.spongepowered.common.scheduler.SchedulerBase.startTask(SchedulerBase.java:179)
	at org.spongepowered.common.scheduler.SchedulerBase.processTask(SchedulerBase.java:165)
	at org.spongepowered.common.scheduler.SchedulerBase$$Lambda$242/15679756.accept(Unknown Source)
	at java.util.concurrent.ConcurrentHashMap$ValuesView.forEach(ConcurrentHashMap.java:4707)
	at org.spongepowered.common.scheduler.SchedulerBase.runTick(SchedulerBase.java:108)
	at org.spongepowered.common.scheduler.SyncScheduler.tick(SyncScheduler.java:51)
	at org.spongepowered.common.scheduler.SpongeScheduler.tickSyncScheduler(SpongeScheduler.java:191)
	at org.spongepowered.mod.SpongeMod.onTick(SpongeMod.java:271)
	at net.minecraftforge.fml.common.eventhandler.ASMEventHandler_10_SpongeMod_onTick_ServerTickEvent.invoke(.dynamic)
	at net.minecraftforge.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:90)
	at net.minecraftforge.fml.common.eventhandler.EventBus.post(EventBus.java:632)
	at net.minecraftforge.fml.common.eventhandler.EventBus.post(EventBus.java:588)
	at net.minecraftforge.fml.common.FMLCommonHandler.onPreServerTick(FMLCommonHandler.java:274)
	at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:602)
	at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:471)
	at java.lang.Thread.run(Thread.java:748)

[jbachorik]

Is this an actual Error terminating the JVM? Or is it just appearing in log/stderr?
The only thing I can think of is MethodInvocationRecorder failing to record exit event, leading to an exception. However, the all-catching try/catch block around any injected code should prevent this taking down the whole application.

[hsyyid]

@jbachorik Thanks for the fast reply. Yes the whole JVM crashes. And yeah I thought the try catch would eat the exception but it didn't.. I did use my fork when testing though, but all I changed was commenting out your getCommonSuperclass method that I made the other issue about

[jbachorik]

This might explain a bit the failure. When you disable getCommonSuperclass the bytecode stack frames can get corrupted and you will get undefined behaviour. I am working on the issue causing you to remove getCommonSuperclass but it is pretty complex one :/

[jbachorik]

Could you try the testcase with the latest dev version? I have implemented custom stackmap frame generation and the problems related to getCommonSuperclass should be gone by now.

[hsyyid]

Sure, will do

…

On Sun, Oct 29, 2017, 3:03 PM Jaroslav Bachorik ***@***.***> wrote: Could you try the testcase with the latest dev version? I have implemented custom stackmap frame generation and the problems related to getCommonSuperclass should be gone by now. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#288 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGgQ8yEVY54lVd8Wob_grNuqiovlVp58ks5sxMwLgaJpZM4P0vKt> .

[hsyyid]

@jbachorik Sorry took me a while.

Was that supposed to fix #283 ?

If so, I am still getting the error using the test environment that is linked on that issue.

[jbachorik]

I'm sorry for the slow turnaround. Is that problem still reproducible? It should generate a hs_err file in the workdir - if you can find it there somewhere, can you attach it here?
Thanks!

[jbachorik]

Ping?

[jbachorik]

Any news here?

[jbachorik]

There was a bunch of fixes on the stackmap frame front since February. Can you retest with the latest dev?

[hsyyid]

@jbachorik Ok, l will try to get around to it soon.

Thanks!

[jbachorik]

Any results yet?

[jbachorik]

@hsyyid Ping?

[hsyyid]

@jbachorik Sorry for taking so long. I've got time this week to test this out.

Side note: would profiling using btrace substantially impact performance of the running application? Specifically if profiling for an extended period of time

[jbachorik]

Any success?
As for the profiling - for production time profiling BTrace is not the right tool. There is JFR which is specifically designed for very low overhead continuous profiling and it achieves that by being plugged in directly into JVM native parts. BTrace can't compete with that.

[jbachorik]

Closing due to inactivity.