panic: runtime error: slice bounds out of range in lumberjack.go:269

[cep21]

Hi,

After about 20-ish hours of working my application crashes with the following panic() in lumberjack.

Could there be some kind of out of order condition that could cause files[] to panic?

Using version:

                    "ImportPath": "github.com/natefinch/lumberjack",
                    "Comment": "v1.0-2-ga6f35ba",
                    "Rev": "a6f35bab25c9df007f78aa90c441922062451979"

panic: runtime error: slice bounds out of range

goroutine 61 [running]:
github.com/natefinch/lumberjack.(*Logger).cleanup(0xc208082d20, 0x0, 0x0)
    /obfuscated/Godeps/_workspace/src/github.com/natefinch/lumberjack/lumberjack.go:269 +0x513
github.com/natefinch/lumberjack.(*Logger).rotate(0xc208082d20, 0x0, 0x0)
    /obfuscated/Godeps/_workspace/src/github.com/natefinch/lumberjack/lumberjack.go:179 +0xb0
github.com/natefinch/lumberjack.(*Logger).Write(0xc208082d20, 0xc208e45900, 0x1cf, 0x247, 0x0, 0x0, 0x0)
    /obfuscated/Godeps/_workspace/src/github.com/natefinch/lumberjack/lumberjack.go:131 +0x316
bytes.(*Buffer).WriteTo(0xc20b172e00, 0x7f5f3f4a57e0, 0xc208082d20, 0x0, 0x0, 0x0)
    /usr/src/go/src/bytes/buffer.go:202 +0xda
io.Copy(0x7f5f3f4a57e0, 0xc208082d20, 0x7f5f3f4a5790, 0xc20b172e00, 0x0, 0x0, 0x0)
    /usr/src/go/src/io/io.go:354 +0xb2
github.com/Sirupsen/logrus.(*Entry).log(0xc2097d4140, 0x4, 0xc209018030, 0x2c)
    /obfuscated/Godeps/_workspace/src/github.com/Sirupsen/logrus/entry.go:94 +0x4d1
github.com/Sirupsen/logrus.(*Entry).Info(0xc2097d4140, 0xc217d53ba8, 0x1, 0x1)
    /obfuscated/Godeps/_workspace/src/github.com/Sirupsen/logrus/entry.go:119 +0x7f

This looks like this area of code for me:

    if l.MaxBackups > 0 {
        deletes = files[l.MaxBackups:]
        files = files[:l.MaxBackups]
    }

[natefinch]

Thanks for the bug report. I'm traveling today but will take a look at it tomorrow.

[natefinch]

It looks like you're using lumberjack v1. I would recommend switching to lumberjack v2. (gopkg.in/natefinch/lumberjack.v2). I made several improvements, and it's currently in production use in a large number of installations as a part of Juju (https://jujucharms.com). I'll look at this panic, but I wouldn't recommend using v1 if you have the option. It's deprecated in favor of v2.

[cep21]

Hi,

Thanks for looking into this.

I'm developing off of the master branch and using godep to manage the dependencies of my binary. Most open source golang projects release the latest version of their code on the master branch.

It appears you've deprecated your master branch. The behavior most consistent with the golang community would be to have the latest version of your code on the master branch and save tags for people that want a specific API. Deprecating the master branch could lead to confusion for people using go get on this github repository.

Rather than deprecated it, why not remove or rename it to prevent any confusion?

[franklinwise]

Agree with @cep21

[natefinch]

You can use go get to get the v2 branch of this code by simply doing go get gopkg.in/natefinch/lumberjack.v2. Using gopkg.in to control versioning of repos is fairly common practice, or at least not uncommon.

I could, in theory, break or remove the master branch so that no one can use it, but that doesn't seem very user friendly. I put a deprecation warning in the readme for the master branch... unfortunately there's no way to emit a warning when you compile, other than to actually break the code and stop it from compiling, which I don't really want to do (and which wouldn't work if you're pinning the revision using godep anyway).