ERROR io.netty.handler.codec.EncoderException: String too big (was 32789 bytes encoded, max 32767)

Discussion in 'Spigot Help' started by FrogBarZ, Jun 12, 2015.

  1. Omnivion


    If someone has the exploit client, send me a PM. I think backported the fix to 1.7.10, but I haven't been able to test it.
  2. Apparently updating to 1.8.7 should fix this. (atleast thats what I heard.)
  3. Could you just check the length of the line before its sent to the client using protocol lib same with if the client attempts to create the sign?
  4. Anyone know at least a temporary fix? I can't even find the specific area that's causing the problem. I tried regenning an entire section where I thought the problem was and it didn't fix anything.
    I tried investigating this one and it seems like a no-go for my situation. I have GP logging all the signs that's been posted on the console and upon search, I didn't find any signs that had a | on it within the vicinity
  5. Well I know that is the symbol used but when the exploit actually works the sign shows up blank (even though there are acutally |'s on it), so that may be why it doesn't detect it. Sorry about that. Try searching for blank signs maybe?
  6. My server's 1.8.3r2 spigot, can I do //replacenear 1000 wall_sign 0?
  7. Dacon


    If you update to 1.8.7 there's no need to get rid of the signs
    Source: (had problem, fixed by updating)
  8. Really? but same Plugins? only the .jar will be changed?
  9. I'm almost 100% sure you need to remove the signs if you update. All the update does it make it so you can't place the signs.
    • Agree Agree x 1
    • Funny Funny x 1
  10. How can I remove them?, I can't even get close to the spawn, How can I know where are the signs? I did //replacenear 1000 wall_sign 0 and //replacenear 1000 sign 0 but same problem
  11. Same problem here, don't even know where the sign is. Downgrading is not an option. WorldEdit ineffective since sign location is unknown. Used Logblock to rollback all sign edits in 10 days but still doesn't solve the crux of the problem. Updating to 1.8.7 will take a lot of time and effort and break some plugins.

    Samistine provided a solution I haven't verified yet:

    Code (Text):
    package com.samistine.samistinesignfix;

    import java.util.Arrays;
    import org.bukkit.Bukkit;

    import org.bukkit.block.Block;
    import org.bukkit.block.Sign;
    import org.bukkit.event.EventHandler;
    import org.bukkit.event.Listener;

    public class SamistineSignFix extends JavaPlugin implements Listener {
        public void onEnable() {
            getServer().getPluginManager().registerEvents(this, this);
        public void onChunkLoad(ChunkLoadEvent e) {
            for (int x = 0; x < 15; x++) {
                for (int y = 0; y < (e.getWorld().getMaxHeight() - 1); y++) {
                    for (int z = 0; z < 15; z++) {
                        Block block = e.getChunk().getBlock(x, y, z);
                        if (block.getState() instanceof Sign) {
                            Sign sign = (Sign) block.getState();
                            String text = Arrays.toString(sign.getLines());
                            if (text.length() > 100) {
                                deleteBlock(sign, text);
        public void deleteBlock(final Sign sign, final String text) {
            Bukkit.getServer().getScheduler().scheduleSyncDelayedTask(this, new Runnable() {
                public void run() {
                    System.out.println("Deleting invalid signs at " + sign.getLocation().toString() + " :");
                    sign.setLine(0, "§3§lSAMISTINE");
                    sign.setLine(1, "§3§lIS FREAKING");
                    sign.setLine(2, "§3§lAwesome");
                    sign.setLine(3, "§4§l:P");
  13. As much as I don't want to loop through every block in every chunk that's loaded, this seems to be a viable solution until someone makes one that uses protocollibs.

    Update: Just tested it and just as I thought it causes too much stress to the server to loop through every block in every loading chunk. Gonna try come up with a more efficient solution.
    #33 Htgan, Jun 13, 2015
    Last edited: Jun 13, 2015
  14. Dacon


    The bugged signs no longer crashed clients after updating. Also with the update, you can still place the sign however it will not do anything besides initially crashing the user who's placing it.
    • Informative Informative x 2
  15. Thanks for the info, by updating you mean client update or server update?
  16. I officially fixed mine an hour ago, here's what I did,
    Update your server to 1.8.7 ( By installing the latest Buildtools )
    Install the given plugin which can help fix the problem ( ) Thank you Samistine!
    and try to //rg replacenear 500 wall_sign 0 and //rg replacenear 500 sign 0

    and It basically fixed my problemo.
  17. Omnivion


    Why not this:
    Code (Text):

        // register the event
        public void onChunkLoad(ChunkLoadEvent event)
            // loop through all tile entities in the chunk
            for (final BlockState state : event.getChunk().getTileEntities())
                // if the tile entitiy is not a sign, move on
                if (!(state instanceof Sign)) continue;
                // if it is a sign, throw it in a variable
                final Sign sign = (Sign) state;
                // loop through the sign's lines
                for (int x = 0; x < sign.getLines().length; x++)
                    // if the line isn't super long, move on
                    if (!(sign.getLine(x).length() > 25)) continue;
                    // otherwise, replace the long string with "???"
                    sign.setLine(x, "???");
                    // Force-update the sign, without calling a physics update
                    // UNSURE IF NEEDED //
                    // sign.update(true, false);
  18. Can you tell me where did you learn deez stuffs? I'm so interested
  19. Omnivion


    Javadocs :)
  20. I experienced this on our server today. Thought the server was patched with the latest 1.8.6 build, but I guess that wasn't the case (or I didn't have the latest build)-- nonetheless, updated to 1.8.7 and everything returned to normal.

    Thanks for this thread & the java snippets!