x4e / PaperBin

An experiment at improving the performance of PaperMC
Other
96 stars 8 forks source link

Dupe exploit #31

Closed comendantmc closed 3 years ago

comendantmc commented 3 years ago

Hi, my players noticed a new dupe exploit involving PaperBin on server restarts/crashes. Items are being duplicated by moving things from enderchest to normal chests. I thinks it has something to do with world/player files being saved separately. Another thing I noticed the server can be crashed more easily when I'm running PaperBin. After the crash I got hs_err files which I suppose unique to PaperBin as I never got them running other builds. The players are also lose their 0.5-1 hour progress which can be dupe exploited too.

Thanks for your work anyway, it's a great project, I hope you're not abandoning that

x4e commented 3 years ago

new dupe exploit involving PaperBin

Is the dupe exploit only possible when PaperBin is loaded? Can you provide steps to reproduce?

After the crash I got hs_err files

Can you send them? You can send them privately to me at x4e_x4e at protonmail dot com.

Overall I do not plan to support PaperBin any more but I can apply simple patches.

comendantmc commented 3 years ago

I just sent you an email with my hs_err files. Regarding the steps to reproduce the dupe exploit, it's quite simple: you just move things from your enderchest/inventory to a normal chest (or other way around, I'm not sure) and after the server restarts, you've got the items in both your enderchest and the normal chest

RemainingToast commented 3 years ago

That is just desync between player inventory and world saving, also it pretty much effects every server that restarts

comendantmc commented 3 years ago

I'm pretty sure I don't have that problem without PaperBin. But actually it shouldn't happen on PaperBin either. Aren't the world and player files saved on the server shutdown?

x4e commented 3 years ago

Not sure. I know that other servers have had this problem before, maybe ask some other server operators. I doubt that it is caused by PaperBin however.

Thank You for sending the crash dumps. Some of the crashes seem to be caused by the JVM running out of available memory, so you could try allocating more memory to the JVM.

The rest of the crashes seem to be internal JVM bugs, related to GC. These could be solved by allocating more memory but if not you would have to get them fixed on the jvm itself. e.g.:

---------------  T H R E A D  ---------------

Current thread (0x00007f0e68086a60):  GCTaskThread "GC Thread#2" [stack: 0x00007f0e2c2fd000,0x00007f0e2c3fd000] [id=4288]

Stack: [0x00007f0e2c2fd000,0x00007f0e2c3fd000],  sp=0x00007f0e2c3fb9c0,  free space=1018k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x6e851c]  G1ParScanThreadState::copy_to_survivor_space(G1HeapRegionAttr, oopDesc*, markWord)+0x18c
V  [libjvm.so+0x6e5cbb]  G1ParScanThreadState::trim_queue_partially()+0x86b
V  [libjvm.so+0x7005a9]  G1ScanHRForRegionClosure::scan_heap_roots(HeapRegion*)+0x859
V  [libjvm.so+0x6f9bed]  G1RemSet::scan_heap_roots(G1ParScanThreadState*, unsigned int, G1GCPhaseTimes::GCParPhases, G1GCPhaseTimes::GCParPhases)+0x24d
V  [libjvm.so+0x69d713]  G1EvacuateRegionsTask::scan_roots(G1ParScanThreadState*, unsigned int)+0x43
V  [libjvm.so+0x69dfe0]  G1EvacuateRegionsBaseTask::work(unsigned int)+0xa0
V  [libjvm.so+0xef00ad]  GangWorker::loop()+0x4d
V  [libjvm.so+0xe55baf]  Thread::call_run()+0xff
V  [libjvm.so+0xbc77e7]  thread_native_entry(Thread*)+0xe7

and

---------------  T H R E A D  ---------------

Current thread (0x00007fed4007a570):  GCTaskThread "GC Thread#4" [stack: 0x00007fecf35f4000,0x00007fecf36f4000] [id=4097192]

Stack: [0x00007fecf35f4000,0x00007fecf36f4000],  sp=0x00007fecf36f2930,  free space=1018k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x6a5772]
V  [libjvm.so+0x6a2623]
V  [libjvm.so+0x6be3d4]
V  [libjvm.so+0x6b6060]
V  [libjvm.so+0x660137]
V  [libjvm.so+0x660b6d]
V  [libjvm.so+0xe5ee7d]
V  [libjvm.so+0xdc4341]
V  [libjvm.so+0xb6552f]

You could also try updating to one of the latest version 16 JVMs to see if they have it fixed.

comendantmc commented 3 years ago

Ok, thanks for looking into the crash reports, I'm gonna try using 16 JVM version then, maybe it helps against some crashes. The memory related crashes was a while ago, they were gone when I upgraded my hardware