Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash due to incompatibility with RebornCore due to adding class to signed package #68

Closed
sblectric opened this issue Apr 26, 2017 · 15 comments

Comments

Projects
None yet
4 participants
@sblectric
Copy link

commented Apr 26, 2017

TickProfiler seems to be looking for javassist.ClassLoaderPool, which causes the server to crash.

Pastebin: https://pastebin.com/G9wChTBw

Forge version 13.20.0.2282

@nallar

This comment has been minimized.

Copy link
Member

commented Apr 27, 2017

@cjm721

This comment has been minimized.

Copy link

commented May 8, 2017

Is there a way to disable that verification check?

For me the class loader that is doing it is inside Reborn Core.

@modmuss50

This comment has been minimized.

Copy link

commented May 10, 2017

I believe the issue is that we are both using different versions of java assist. I am using 3.22.0-CR1, that is 1 version newer than your's. I think if you update it will fix the conflict with RebornCore.

@modmuss50

This comment has been minimized.

Copy link

commented May 10, 2017

Linking the issue on my tracker for reference: TechReborn/RebornCore#48

@nallar

This comment has been minimized.

Copy link
Member

commented May 10, 2017

I add a class into the javassist package, which is technically wrong, but the least messy workaround to implement this: https://github.com/nallar/ModPatcher/blob/1.11.2/src/main/java/javassist/ClassLoaderPool.java

Usually LaunchClassLoader doesn't enforce signing (I could be presuming this incorrectly.). I don't add the javassist package as a classloader exclusion either, only a transformer exclusion. Presumably you add a classloader exclusion for that package, or something else does, so the system classloader is being used which does care about signing?

Completely unrelated, but I find it quite funny that you chose to use javassist to implement mixins, when I chose to migrate away from javassist to asm for my mixin implementation.

@nallar nallar self-assigned this May 10, 2017

@nallar nallar added the 1.11.2 label May 10, 2017

@modmuss50

This comment has been minimized.

Copy link

commented May 11, 2017

I dont think there is a lot more I can do to fix this on our end. I added javaassist to the exclusions list and that produced this crash: https://gist.github.com/modmuss50/38ef0076ee394cbbcd1fbfda24bbb630

I think the best thing we both could do to fix it would be to repackage javaassist into our own packages. You could also try and move that class out from javaasist but I see how that could be an issue.

If you have any ideas on how this could be solved I would love to hear them.

@nallar

This comment has been minimized.

Copy link
Member

commented May 11, 2017

You could stop signing packages in your jar which are from other libraries, which would resolve this. Currently you sign your own code as well as signing your dependencies.

In the long term I should get javassist changed to make the methods I need to override not package private but that will take some time for a new release.

Repackaging would work but adds the overhead of having the same classes loaded multiple times under different names. Best to avoid that unless absolutely necessary.

nallar added a commit that referenced this issue May 11, 2017

@nallar nallar closed this in a51f51f May 11, 2017

@nallar

This comment has been minimized.

Copy link
Member

commented May 11, 2017

Didn't fix it, just broke it differently. Oops. :(

@nallar nallar reopened this May 11, 2017

@modmuss50

This comment has been minimized.

Copy link

commented May 11, 2017

I will try and figure out how to exclude it from being signed.

@nallar

This comment has been minimized.

Copy link
Member

commented May 11, 2017

Please revert the commit adding a classloader exclusion for javassist - I thought you might already be doing that and meant to remove it, adding it definitely won't help. :(

Should have another fix/workaround to try tomorrow if not later tonight.

@nallar

This comment has been minimized.

Copy link
Member

commented May 11, 2017

I will try and figure out how to exclude it from being signed.

Nevermind, you don't need to. Should be able to get it working anyway. Thanks for the help.

@nallar nallar changed the title [1.11.2 jenkins 10] Crash due to missing dependency Crash due to incompatibility with RebornCore due to adding class to signed package May 11, 2017

@nallar nallar added the bug label May 11, 2017

@nallar

This comment has been minimized.

Copy link
Member

commented May 12, 2017

Latest version sort-of fixes this, but it will only work if you rename TickProfiler to something before "R" in the alphabet. (try _TickProfiler.jar).

CoreMods are only sorted by file name. Working on another workaround. :/

@cjm721

This comment has been minimized.

Copy link

commented May 12, 2017

Oh that beings be back to the 1.4.7 tick threading days. Will throw it up on my server in annoyed when get home.

@cjm721

This comment has been minimized.

Copy link

commented May 14, 2017

Been running with version 15 fine (After adding the _)

@nallar

This comment has been minimized.

Copy link
Member

commented May 14, 2017

Should now work fine regardless of naming.

@nallar nallar closed this May 17, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.