Time: 07/09/15 22:19

Description: Ticking block entity

java.lang.NullPointerException: Ticking block entity

at logisticspipes.proxy.specialinventoryhandler.StorageDrawersInventoryHandler.decrStackSize(StorageDrawersInventoryHandler.java:314)

at logisticspipes.modules.ModuleExtractor.tick(ModuleExtractor.java:185)

at logisticspipes.modules.ChassiModule.tick(ChassiModule.java:132)

at logisticspipes.pipes.basic.CoreRoutedPipe.updateEntity(CoreRoutedPipe.java:468)

at logisticspipes.pipes.basic.LogisticsTileGenericPipe.func_145845_h(LogisticsTileGenericPipe.java:202)

at net.minecraft.world.World.func_72939_s(World.java:1939)

at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:489)

at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:636)

at net.minecraft.server.dedicated.DedicatedServer.func_71190_q(DedicatedServer.java:334)

at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:547)

at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:396)

at net.minecraft.server.MinecraftServer$2.run(MinecraftServer.java:685)

A detailed walkthrough of the error, its code path and all known details is as follows:

-- Head --

Stacktrace:

at logisticspipes.proxy.specialinventoryhandler.StorageDrawersInventoryHandler.decrStackSize(StorageDrawersInventoryHandler.java:314)

at logisticspipes.modules.ModuleExtractor.tick(ModuleExtractor.java:185)

at logisticspipes.modules.ChassiModule.tick(ChassiModule.java:132)

at logisticspipes.pipes.basic.CoreRoutedPipe.updateEntity(CoreRoutedPipe.java:468)

at logisticspipes.pipes.basic.LogisticsTileGenericPipe.func_145845_h(LogisticsTileGenericPipe.java:202)

-- Block entity being ticked --

Details:

Name: logisticspipes.pipes.basic.LogisticsTileGenericPipe // logisticspipes.pipes.basic.LogisticsTileGenericPipe

Block type: ID #2043 (LogisticsPipes Pipe Block // logisticspipes.pipes.basic.LogisticsBlockGenericPipe)

Block data value: 0 / 0x0 / 0b0000

Block location: World: (1509,63,972), Chunk: (at 5,3,12 in 94,60; contains blocks 1504,0,960 to 1519,255,975), Region: (2,1; contains chunks 64,32 to 95,63, blocks 1024,0,512 to 1535,255,1023)

Actual block type: ID #2043 (LogisticsPipes Pipe Block // logisticspipes.pipes.basic.LogisticsBlockGenericPipe)

Actual block data value: 0 / 0x0 / 0b0000

LP-Version: 0.9.2.46:false

Pipe: logisticspipes.pipes.PipeLogisticsChassiMk1

Transport: logisticspipes.transport.PipeTransportLogistics

Router: ServerRouter: {ID: 2, UUID: 7e828c00-e686-4fad-9cf3-9e51ae5431d5, AT: (0, 1509, 63, 972), Version: 5), Destroied: false}

stillNeedReplace: false

Stacktrace:

at net.minecraft.world.World.func_72939_s(World.java:1939)

at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:489)

Interestingly, I cannot reproduce this issue, at least not with the latest versions of LP & SD, in a dev environment.

I've tried putting extractor module Mk1, Mk2, & Mk3 in a chassis pipe adjacent to a Drawer controller, and it seems to work flawlessly- working as expected, so I'm not sure what could possibly going wrong. :/

Relly you answer on post that be old I forgot that post from this time logistic pipes have 10 or more updates and really you only write posts become you don't even check date issue

@whitenet this is an issue on Github, not a forum thread. If your problem is solved, the issue should be marked as "closed," otherwise people will assume that the issue still exists, and try to figure out what is wrong and how to fix it.

Correct.

This NPE is still possible, so this should probably be prevented:

We just had the same server crash-

http://pastebin.com/gxB0ctYN

same error aswell tried to pull out items from the drawer controleller with a chasis mk1 and a mk3 exractor module and then it crashed --> http://pastebin.com/Qybdn5Vx

We are on a large multiplayer server, the person that caused this crash never came forward so we will not be able to retry whatever caused it.

@hron84 You are right, but I don't think you can just return null without adding null checks in a LOT of different places.

It's called by ModuleExtractor, (Which actually DOES have a null check.)
It's called by ModuleQuickSort, (I guess it would just skip that tick, and move the lastStack stuff?)
It's called several times in ModuleElectricManager, (Would be a weird edge usage case, but still)
It's called in ModuleElectricBuffer, (another strange use case)
It's called in ModuleCCBasedQuickSort, (this one would be easy to add a null check in)
It's called in ModuleApiaristAnalyser, (This would be a REALLY weird use case.)

So I'm not really sure if it's a good idea to just have it return null, unless we're sure that ModuleExtractor is the only object that can cause this error...

@ProsperCraft @fitheach could you please try out the latest LP version? Storage Drawers integration got a big update in this release...

@hron84 While that is possible, None of the changes I authored got anywhere near the decrStackSize() method, so I highly doubt that this null issue has been affected by the recent storage drawer changes.

Interestingly, I couldn't reproduce the issue when I tried to much earlier. Though once Davboecki mentioned the line number, I can definitely see how the NullPointer is occurring. However, at first glance, it looked like the fix was going to be pretty involved, and not incredibly simple, so I haven't had much time to look into how to solve it in more detail.

If someone could have a more specific replication directions (like with pictures) I'm pretty sure I can spend some time exploring the root of the issue, since I was somewhat unsuccessful reproducing it before.

@1n5aN1aC as someone who do not know too much about MC development, it should be enough if you just check if stack is not null. Possibly moving the getStoredItemCopy call before decreasing the stack should be also good, and if you get null, you can return with null without decreasing the stack. After you decreased the stack, you can set size to an object that is already null-checked.

huh, I guess decrStackSize() can return null in some cases, even though there isn't null checks everywhere for it...

Anyways, I've made a change that I think fixes this, but I put a System.Out.println() there, so I can see if it's ever used, and I still have not been able to reproduce the error...

@whitenet or @fitheach, can either of you show a screenshot of your exact setup where you were able to cause this error, so that I can see if these changes fix it?

I'm starting to wonder if this issue has something to do with applied energistics in any way.

It doesn't make a whole lot of sense to me, but I have not been able to reproduce this in my test environment of just StorageDrawers and LP, and yet multiple people have mentioned sending the items into AE.

Here's what I tried:

With Mk3 Extractors on the bottom and side (because that's what you had) and an Itemsink Module set to default route on the left drawer. I'm using the new StorageDrawer infinite storage upgrades to make testing easier.

EDIT: Just realized I'm testing with my possible fix enabled. One sec, will add a debug print command and test again.

Nope, tested again with a System.out.println() in the additional null check, and it never got called...

hmm so might be worth to try with ae ? my setup was only from the side i didnt even come to putting in the module into the bottom one. if you dont mind try with ae and a chassis mk1 into just a basic logistic pipe set to default route which points into a me interface. This is excact setup i have then

i have absolutely no idea it crashed me when i tried to load up the world when it crashed but when i rebuild it fast in a diffrent new world it was fine. -- im gonna try loading my backup again and build it again if its not working its something with already existing worlds >_>

you can world edit out the block that reports in the crash log and it will stop the crashes.

as for what happend this is after the 1. incident i just quickly rebuild it but it will crash as soon as i put in the extractor modules. this all leads to basicly just an me interface the pack im playing on is infinity evoleved with some extra mods like: veinminder etc. if you need more information or more screenshots let me know. Hope i could help somehow with this

Ok.....

This is a picture of the setup. I did not know if chunk boundaries were an issue, so I decided to test this out across Chunk boundaries first. Colored wool should explain.
Full SIze Picture

These two pictures show what is in the MK2 pipes attached to the storage controller and the Macerator. At this point the MK2 pips attached to the AE Interfaces are empty.
Full SIze Picture

Full SIze Picture

Everything goes well. Until I involve AE into the mix

• I start out with the above described setup working fine.
• Placing a provider (MK1 or MK2) into Either/Both of the MK2 pipes next to an AE Interface will crash to desktop.
• Removing the Provider from the controller and placing into the AE will crash to desktop.
• Having BOTH the Item Sink and Provider Module in the AE interface with nothing in the MK2 next to the contoller provides No Crash.
• The crash does not happen if nothing is moving between the networks.
• Crash Report

Further testing of moving between the AE system and the Storage Controller cause a CTD.
(No pictures, sorry it is late and I'm tired.)

I came across this thread while testing for reasons for specific chunks on our server not to save on chunk unload/load. @Slind14 might be able to provide the logs from the server when that happened.

will this help http://stackoverflow.com/questions/3589308/arraylist-and-multithreading-in-java
https://www.google.nl/#q=java+how+to+use+hashmap+on+a+different+thread

again, this has most likely nothing to do with multi threading. If you read the java doc closely it describes the case with iteration. No need for any multi threading to be involved. Anyways the author of the mod is inactive according to the repo, so unless someone picks it up, its likely to never be fixed as debugging such a bug is a pain the ass.

@loordgek those solutions don't help in this case as to make it usable across different threads you need to override the hashmap with a threadsafe equivalent and it's not in an LP class so very hard to do that

@Slind14 indeed but with a hashmap 99.99% of the time multithreading is the cause for that error

last respond from my side. That is definitely not the case. I would say in +95% of the cases in relation to minecraft it isn't.

@Slind14 ...Inactive? Does 32 days really count as inactive to you, especially when he's accepting pulls and commenting during that time? (Or maybe you were just looking at the 'main' branch, which isn't the current primary branch.)

Anyways, I'm going to have to leave the ConcurrentModificationException to @theZorro266 or @davboecki. I don't know enough about the internals of Logistics pipes to have any clue where that might be coming from.

I think I've fixed the NullPointerException. Doing testing with AE now to be sure.

As for the IllegalArgumentException: zero count needed, promises not needed reported by @bookerthegeek I'm actually afraid that might be caused by my earlier accepted pull that added polymorphic support for StorageDrawers... Not sure yet, but this is definitely from RequestTreeNode.java#L119 which might be related. maybe @davboecki could shine some light on if that change could be the cause of this?

@1n5aN1aC ahh yeah I did, 👍

@1n5aN1aC I'll redo the testing tonight and get you those crash reports for each time. Any setup in particular you would like me to test out other then what is already there?

This all came about due to chunks not saving on our server, in my base, when I moved the mats for the creative energy cell from one base to another. Long store short I'm out 2 weeks of work. Testing in singleplayer, I recreated my base, and slowly started to remove things. Weirdly in single player when I applied energy to everything is when I started to crash.

So I removed energy and started to remove molded items. Finally got down to AE, LP & Storage drawers. On the server the SD Controller and AE system are in separate chunks.

I am assuming that due to server magic that the server is not crashing but just not saving the chunks. i.e. why I asked for slind14 for the logs.

If you have a version with any extra debugging info I'll be more then happy to test with that of you like, of if you want I can test with a dev build.

Alright, so..... now I'm thinking that my change to support a polymorphic in StorageDrawers is causing some unforeseen consequences. :(

@bookerthegeek could you check what version of StorageDrawers you're running on as well?
Ok, so a couple of things to try:

1. Try to use the absolute minimum set up possible, so it's easier to set up in a dev environment, and trace the crash back, looking at the stack and such.
2. I couldn't tell for sure, but in your picture, it looked like the StorageDrawers were locked. It's possible the wonkiness lies in that, so see if it still has problems when the drawers aren't locked.
3. I'm really not sure anymore, because there's like 3 different crashes going on in this thread, but if you ever get the java.lang.NullPointerException: Ticking block entity that mentions StorageDrawersInventoryHandler.decrStackSize then try this version, and see if the problem still happens: {Link removed; fix has been merged into LogisticsPipes}

@Slind14 Are you sure this is the same problem? the error looks completely unrelated to StorageDrawers, and possibly even LogisticsPipes, but it's hard to say without more information.

@bookerthegeek Thank you very much, looks like it does have something to do with AE. I'll have to expand my debugging in the dev environment to include that. Question though: was the error you linked what you always got? I ask because it sounds like the same error, but the error isn't the same as the problem I was looking at (java.lang.NullPointerException: Ticking block entity @ StorageDrawersInventoryHandler.decrStackSize() )

At any rate, I'm not sure if these errors are actually the same, or just related. But I'll definitely do some testing with AE in the dev environment when I get back to my computer.

that error that @Slind14 is similar to things i ran intro recenctly (other context though), minecraft is made single threaded so it uses regular hashmaps and arraylists, those are not threadsafe, if a mod uses those from another thread then things will crash

This is more likely caused by an iteration than anything else:
http://docs.oracle.com/javase/7/docs/api/java/util/ConcurrentModificationException.html

yeah a simple iteration is enough to cause the crash because hashmaps and arraylists are not threadsafe and should only be used on 1 thread

YUS Thank you soooo much <3 it works all for me

@fitheach so the build I linked fixes the issue you had? That's great!

Unfortunately, all it means is the error this issue was originally created for is fixed (the java.lang.NullPointerException: Ticking block entity at logisticspipes.proxy.specialinventoryhandler.StorageDrawersInventoryHandler.decrStackSize error)

Could you make sure that it was this change that fixed it by making sure there's a bunch of debug lines in the console saying "look at me!"? 😄 If so, I'll make a pull request with the fix.

As for the IllegalArgumentException: zero count needed, promises not needed error....
I think I know the cause of it, but I can't figure out precisely HOW.

well since im using the curse launcher i cant find the logs or im just to blind but i changed nothing to the setup b4 so i would give my word that it fixed it.

You can also go to the folder this Minecraft instance is installed in and open the folder logs. There you can find all your logs.

uhhh problem is how do i look at the console in singleplayer ?! T__T I dont know how

If you are using the vanilla minecraft launcher, when you close minecraft, and the launcher re-opens, it should be on one of the other tabs.

If you're pretty sure that you did the same thing as before, and it continues to work, I guess that's good enough confirmation that it works. 😉

On Dec 1, 2015, at 10:56 PM, Fitheach [email protected] wrote:

uhhh problem is how do i look at the console in singleplayer ?! T__T I dont know how

—
Reply to this email directly or view it on GitHub.

@1n5aN1aC

Running with the latest version from the Jenkins #70 I can't reproduce this error no matter how hard I tried. Glad to know it looks like it is fixed.

Oh really? That's great, since it implies that this problem may be completely fixed, with the possible exception of the ConcurrentModificationException error, which I didn't really understand the circumstances of anyways.

@1n5aN1aC tag me up if you need more testing done.

@bookerthegeek well, if you haven't been able to cause the crash anymore, despite how hard you try, I guess I'd consider this bug fixed.

The only exception to this might be the ConcurrentModificationException which may or may not be related to the issue that appears to be fixed.

Two question:

• Could you please upload the full log to https://gist.github.com and link it back here?
• Could you please make a screenshot about your setup?

Full crash log
https://gist.github.com/whitenet/dd570c13a29560964421

i can't make screenshot because this make me crash but when you connect mk1 whith extraction card to storage drawer controller world crash instantly

Thanks for describing the situation. Until it will be solved: try to connect mk1 with provider module and use supplier pipe on other side, it is worked for me.

Thanks but this solution works fine but when i tray transfer everything from storage drawers to ae2 i make crash that i make issue :)

Ohh. Import buses make crash too?

No no ae work fine but I love LP and only ae2 use for storage :)
My ae2 have only energy accepter and 7 drive and 1 interface for rest I use LP

i found a solution
it just works if you dont need thaumcraft
i have not red the whole thread
but here is my problem

i wanted to build an endless storage system with lp
i added the mod to ftb ultimate
build the system
it crashed when i wanted to use it
i searched for solutions

Now i found one:

just delete thaumcraft from ftb ultimate and lp works normaly without crashing

@agentk0510 FTB Ultimate is an 1.4.7 pack. The ongoing issue is on 1.7.10. I have absolute no idea how your solution could be related here, but maybe it's because me. If you could explain it with a bit more details, it should help. Please help us to understand your idea about the fix.

I thought this thread IST about ftb, don't it?

@agentk0510 What do you mean under "FTB"? FTB is resolves to Feed The Beast, this is a community, that has a launcher, some different packs and whatnot.

This thread is about an error in Logistics Pipes interacting with Storage Drawers, and possibly has a little bit talk about FTB Infinity Evolved Skyblock or some other FTB packs shipped for MC 1.7.10. But I still not get, what do you want to ask or say. Please unfold your thoughts a little bit further to help us to understand you.

Ohh, and also, Thaumcraft is a very integrant part of FTB Infinity Evolved and Evolved Skyblock packs, many recipes are depending on it,. so deleting Thaumcraft is definitely not a good idea. Also, LP currently has little or no Thaumcraft integration, so I don't think deleting that can solve literally anything.

Fixed the storage drawers integration in 1.12 in build 99 of 0.10.3 – finally. Tested with StorageDrawers-1.12.2-5.4.2