Solved Failed to write core dumps while working with lines of a file

Discussion in 'Spigot Plugin Development' started by jetp250, Apr 30, 2017.

  1. Hey; while I was creating a plugin that has to load files on load and save them on disable; sometimes on disable I get this 'Failed to write core dumps' error; of which I believe most of you have heard at some point.

    However, I have no clue of what could be the cause; in SO they recommend to enable core dumps, but I'm hoping there's some sort of mistake on my side that I could fix.

    Again, pointing out, this doesn't happen every time the plugin is disabled; only sometimes. And yes, it's my plugin; I found the method causing this from the HS_ERR_PID -kind of file that java kindly generated in my server folder.

    Now, the method it was pointing to was this:
    Yes, I know it's ugly. Feel free to point out a cleaner method if you can.
    Code (Java):
    public void save() {
        try {
            if (!this.file.exists())
            final List<String> lines = FileUtils.readLines(file, Channel.CHARSET);
            final List<String> newList = new ArrayList<>();
            newList.add("PREF " + this.getPrefix().replace('\u00a7', '&') + '\n');
            if (this.getPermission() != null)
                newList.add("LOCK " + this.getPermission() + "\n");
            final List<UUID> added = new ArrayList<>();
            boolean prefFound = false;
            boolean lockFound = false;
            for (String line : lines) {
                if (!lockFound && line.startsWith("LOCK")) {
                    lockFound = true;
                if (!prefFound && line.startsWith("PREF")) {
                    prefFound = true;
                final String id = line.contains("MUTED") ? line.replace(" MUTED", "") : line;
                if (id.isEmpty())
                final UUID uid;
                final Channel channel = ChatChannels.getUserMap().get(uid = UUID.fromString(id));
                if (channel != null && channel == this) {
                    newList.add(id + (isMuted(uid) ? " MUTED" : ""));
            for (Player player : players) {
                if (!added.contains(player.getUniqueId())) {
                    newList.add(player.getUniqueId() + (isMuted(player.getUniqueId()) ? " MUTED" : ""));
            FileUtility.writeLines(this.file, newList.toArray(new String[newList.size()]));
        } catch (Exception e) {
            Bukkit.getLogger().log(Level.SEVERE, "Failed to save channel \"" + name + "\"", e);

    Now, pretty much the only calls (or, call, in this case) done to other classes of my plugins are the ones starting with 'FileUtility'.
    The method 'writeLines' is as follows:
    Code (Java):
    public static boolean writeLines(final File file, final String...lines) {
        PrintWriter writer;
        try {
            writer = new PrintWriter(file);
        } catch (FileNotFoundException e) {
            Bukkit.getLogger().log(Level.SEVERE, "Failed to write lines (File does not exist?)", e);
            return false;
        for (String line : lines)
            writer.write(line + '\n');
        return false;
    Now, I can't see anything that could cause this; although I have to admit I'm unsure about what the 'core dumps' (and them not being enabled) means; if someone could explain those briefly, I'd appreciate.

    Can I do anything about this?

    EDIT: The file(s) are empty, too; so unless the 'FileUtils.readLines' is the cause, the Lists being too big shouldn't be the cause.

    The 'players' list only contains me.
  2. sothatsit


    I would guess that this would be caused by the thread stalling for a period of time where Spigot suspects your plugin has stalled and therefore does a core dump to dump what is going on. I don't see where that would happen in your code though, especially considering you said this file is empty. Try placing log messages throughout the save method to see where it stops.
  3. I shall, thanks. Just read about it from wikipedia, learnt absolutely nothing (as they've written it so scientifically I have no idea what most of the words even mean.. ) other than it's somehow related to memory; and seeing where others have gotten this error seems to have something to do with working with huge amounts of data. That isn't the case for me, though; interesting.

    Will be back with debugging results.
  4. You might as well post the crash logs. Note that this issue is not directly related to spigot.
  5. May as well.
    Sorry; didn't think of it not being Spigot-related, since it had something to do with my plugin I somehow thought it'd be plugin development related and posted here. I'll keep in mind.

    Now, I just added a massive amount of debugging to the code; but haven't gotten the error again. I'll just keep trying to code the plugin normally and be back when the next one occurs, just like I did before posting.
  6. electronicboy

    IRC Staff

  7. Huh? Could be possible I had one of the 'channel' files open at the moment I reloaded, I'll give that a try.
    Thanks :)

    EDIT: Or not, no effect whatsoever.
  8. electronicboy

    IRC Staff

    where is your channel file?
    are you sure that you're not doing anything that may be editing the actual plugins jar file?
  9. Yes; I'm sure.
    The 'channel files' are located in 'server directory/plugins/<plugin name>/channels/<file name>', and the files are created.

    That code should be everything that modifies / touches the files at all; other than a 'delete' command - which, though, has been proven to work, and has never cause any issues.

    Still haven't gotten the error! Interesting, just before posted this I got it like 3 times in a few minutes.
  10. electronicboy

    IRC Staff

    By any chance are you working in an IDE, and making changes and exporting the plugin jar straight into the plugin folder?
  11. Well, yes?
    Working with Eclipse (no hate, please), and I overwrite the jar each time I export.
    If this could be the cause, interesting; I've always done so without any problems.
  12. electronicboy

    IRC Staff

    That will likely be the cause; sometimes you can get away with it, but in this case looking at the stack trace deeper, what is happening is the JVM is looking up in the classloader for a class, and it's tried to read your jar and the JVM has crashed because the file has changed on disk causing the mappings stored in the JVM and itself to be out
    • Informative Informative x 1
  13. Ah, well. Still though, strange; haven't had this problem before. I guess I'll mark this as solved, but I'd still like to think that wasn't the cause; could be, though, who knows.
  14. electronicboy

    IRC Staff

    Sometimes you can get away with it, e.g. the file doesn't change on disk enough to cause this issue (well, specifically enough for the class you care about), or the class definition is already in memory and so the JVM doesn't need to start checking the jar for the file. It's really all a matter of context and how much happens, the JVM is a complicated beast, sometimes you can get away with stuff like modifying a jar under its toes, other times you're asking for hell...

    There are tricks to get around this, especially on *nix systems (such as macOS ;) ), where you delete the original jar from the disk and replace the file, the JVM will still be able to access the old file (and it will still technically be stored on disk until the file is closed by the JVM), allowing you to "replace" the jar without upsetting the JVM.
    If you'd be able to set this up to happen in eclipse or not is another matter, however
  15. Thanks for the clarification!
    However, is Windows a 'nix' system too? I'm switching from Windows to macOS all the time (and I do the exact same thing on both sides) and this hasn't happened there too. I'd then assume Windows is, too.

    Well, I guess it also depends on the context. This may of have just been something it won't accept. Well, still, now it's work and everything seems to be fine; so I guess it doesn't matter now.
  16. electronicboy

    IRC Staff

    Windows isn't a nix system, nor do I have that much experience with windows overall, however; windows locks files that are actively being used, so I wouldn't be surprised if eclipse was doing something weird in order to get around this, and if windows has the same traits of a file not actually being removed from the disk by the kernel until the file is actually released from all applications.