labstack / gommon Goto Github PK

Logging crashes with "runtime error: index out of range" in the log() function on line 173

f := fmt.Sprintf("%s|%s|%v\n", levels[v], l.prefix, msg)

in Windows in ConEmu console window. Works fine but no colors in mintty. My guess is ConEmu console is not recognized as *os.File and variable levels is not initialized. In my case log() is called from Info() so the level is INFO or 2, which I can see in the stack trace of panic output.

Perhaps, levels should always be initialized to some sensible values in SetOutput().

I was trying out echo, and I used e.Logger to as my application's logger, but I found that file locations in the log output were wrong, they all reported the upper layers of their real locations.

Then I found this commit, which changed runtime.Caller(2) to runtime.Caller(3). I set it back to 2, then everything works just fine.

I wonder why it was set to 3 back then.

gommon v0.3.0 uses github.com/stretchr/[email protected] which in turns uses gopkg.in/[email protected] which suffers a severe CVE long fixed since there is at least a v2.2.8 and even v2.4.0.

By simply, upgrading the yaml dependency, this would avoid having the CVE reported by security scanning tools (lke sonatype).

Is it possible to support SI (power of 1000s, instead of 1024s) with a flag ?

690000 -> 673.83KB
690000 -> 690KB

Hi, I've update echo to v4 and after a go get command I receive:

go build github.com/labstack/gommon/random: module requires Go 1.13
go build github.com/labstack/gommon/color: module requires Go 1.13
go build github.com/labstack/gommon/bytes: module requires Go 1.13

My go version is 1.11 that is supported by Echo v4.

Why this package requires v 1.13?

Using the following configuration in the docker setup and no colors are being printed. Running the application without docker prints color fine.
Docker compose has tty enabled.

	e.Use(middleware.LoggerWithConfig(middleware.LoggerConfig{
		Output: e.Logger.Output(),
	}))

according to Clause 4 of the ISO/IEC 80000 standard and IEEE 1541
among other things, the SI prefixes strictly refer to powers of ten and should not be used to indicate binary multiples

instead the Ki,Mi,Gi,.. prefixes should be used to indicate power of 2s

more on: https://en.wikipedia.org/wiki/Binary_prefix#IEC_prefixes

proposed solution:
change the current units from Si prefixes to Binary prefixes (KB->KiB,MB->MiB,GB->GiB,..)
and then (optionally) add support for Si units

Description

Parse function does not support float values.

Expected behaviour

Support float values.

str := bytes.Format(13231323)
// -> 12.62MB

b, err := bytes.Parse(str)
// b -> 13233029  (truncated float 13233029.12)
// err ->  nil

Actual behaviour

str := bytes.Format(13231323)
// str -> 12.62MB

_, err := bytes.Parse(str)
// err ->  error parsing value=12.62MB

Version/commit

f72d3c883f8ea180da8f085dd320804c41332ad1

In our code base we are wrapping gommon.Log, however when looking at the log output, the referencing sourcecode and line number are incorrect, since gommon.Log uses a hardcoded skip parameter.

Can we make this parameter public, or make a method to be able to change that?

gommon.log produces erroneous JSON output if the passed message contains newline characters or quotes.

	e.Logger.Info(`hello 
	"world"`)

produces

{"time":"2016-12-18T14:51:44+01:00","level":"INFO","prefix":"echo","file":"main.go","line":"28","message":"hello
	"world""}

This means all panics caught and logged by Echo as JSON are not parsable.

func someHandler(c echo.Context) error {
	panic("abcde")
	return c.String(http.StatusOK, "Hello, World!")
}

I set the log's level to OFF and I thought that log function should be fast. However it seemed to be slower than of noop function. I have tested like this:

func BenchmarkEchoLog(b *testing.B) {
	e := echo.New()
	e.Logger.SetLevel(log.Lvl(log.OFF))
	c := e.NewContext(nil, nil)
	for i := 0; i < b.N; i++ {
		c.Logger().Debug("a")
	}
}

func BenchmarkNoop(b *testing.B) {
	noop := func(args ...interface{}) {}
	for i := 0; i < b.N; i++ {
		noop("a")
	}
}

BenchmarkEchoLog-4                  	 1000000	      1778 ns/op
BenchmarkNoop-4                     	30000000	        40.8 ns/op

Using this file:

package main
import "github.com/labstack/gommon/color"
func main() {
   color.Println(color.Green("aaaaa bbbbb"))
}

I just get plain white output.

Hello,

First of all I want to thank you for creating and maintaining this library, I have used it now in production for quite some time and have enjoyed using it thoroughly.

Currently the email package only supports sending either text or html messages, with the text message being chosen when both fields are present.

I have read from various sources that it is considered best practice to include both text and html message bodies in the email so that the email client gets to choose which format to display to the user. I believe this is a fairly simple change in the codebase and am more than happy to contribute myself.

Please let me know how to proceed on this!
Thanks

The problem is on this line:

The panic is fixed v0.0.14 of the upstream go-isatty, via mattn/go-isatty#66

Root cause is here:
golang/go#47776

Here's what the panic looks like on go 1.17:

runtime.sigpanic()
	/usr/local/Cellar/go/1.17/libexec/src/runtime/signal_unix.go:719 +0x396

goroutine 1 [syscall, locked to thread]:
syscall.syscall(0x4321040, 0x1, 0x40487413, 0xc00015b8c0)
	/usr/local/Cellar/go/1.17/libexec/src/runtime/sys_darwin.go:22 +0x3b fp=0xc00015b830 sp=0xc00015b810 pc=0x4061bfb
syscall.syscall(0xc00010cea0, 0xc00015b900, 0x400ee34, 0x100000000000000)
	<autogenerated>:1 +0x26 fp=0xc00015b878 sp=0xc00015b830 pc=0x4067926
golang.org/x/sys/unix.ioctl(0x18, 0x100000004a9d108, 0x4aa6328)
	/Users/jeff/go/pkg/mod/golang.org/x/[email protected]/unix/zsyscall_darwin_amd64.go:731 +0x39 fp=0xc00015b8a8 sp=0xc00015b878 pc=0x4320cd9
golang.org/x/sys/unix.IoctlGetTermios(...)
	/Users/jeff/go/pkg/mod/golang.org/x/[email protected]/unix/ioctl.go:72
github.com/mattn/go-isatty.IsTerminal(0x44ff480)
	/Users/jeff/go/pkg/mod/github.com/mattn/[email protected]/isatty_bsd.go:10 +0x50 fp=0xc00015b918 sp=0xc00015b8a8 pc=0x433f470
github.com/labstack/gommon/color.(*Color).SetOutput(0xc00000e3f0, {0x4609b40, 0xc000010018})
	/Users/jeff/go/pkg/mod/github.com/labstack/[email protected]/color/color.go:146 +0x92 fp=0xc00015b938 sp=0xc00015b918 pc=0x433f8b2
github.com/labstack/gommon/color.New(...)
	/Users/jeff/go/pkg/mod/github.com/labstack/[email protected]/color/color.go:134
github.com/labstack/gommon/color.init()
	/Users/jeff/go/pkg/mod/github.com/labstack/[email protected]/color/color.go:102 +0x4ea fp=0xc00015b968 sp=0xc00015b938 pc=0x4340f6a
runtime.doInit(0x48edce0)
	/usr/local/Cellar/go/1.17/libexec/src/runtime/proc.go:6498 +0x123 fp=0xc00015baa0 sp=0xc00015b968 pc=0x4044c03
runtime.doInit(0x48f2320)
	/usr/local/Cellar/go/1.17/libexec/src/runtime/proc.go:6475 +0x71 fp=0xc00015bbd8 sp=0xc00015baa0 pc=0x4044b51
runtime.doInit(0x48f10c0)
	/usr/local/Cellar/go/1.17/libexec/src/runtime/proc.go:6475 +0x71 fp=0xc00015bd10 sp=0xc00015bbd8 pc=0x4044b51
runtime.doInit(0x48f11a0)
	/usr/local/Cellar/go/1.17/libexec/src/runtime/proc.go:6475 +0x71 fp=0xc00015be48 sp=0xc00015bd10 pc=0x4044b51
runtime.doInit(0x48efba0)
	/usr/local/Cellar/go/1.17/libexec/src/runtime/proc.go:6475 +0x71 fp=0xc00015bf80 sp=0xc00015be48 pc=0x4044b51
runtime.main()
	/usr/local/Cellar/go/1.17/libexec/src/runtime/proc.go:238 +0x1e6 fp=0xc00015bfe0 sp=0xc00015bf80 pc=0x4037ce6
runtime.goexit()
	/usr/local/Cellar/go/1.17/libexec/src/runtime/asm_amd64.s:1581 +0x1 fp=0xc00015bfe8 sp=0xc00015bfe0 pc=0x40652a1
exit status 2

As can currently be seen at https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#golang-github-labstack-gommon, the tests for the bytes package fail on arm64, ppc64el and s390x architectures. This turns out to be because the tests depend on the conversion of the (just) too large float math.Pow(2, 64) to int64 returning MinInt64. On these platforms it seems the conversion saturates and returns MaxInt64. FWIW the standard says:

In all non-constant conversions involving floating-point or complex values, if the result type cannot represent the value the conversion succeeds but the result value is implementation-dependent.

so the tests shouldn't depend on this, or if this behaviour is important then the implementation needs to take care to enforce it. I don't really see a reason why the tests need to push the edge of the range of int64 like this so I'll probably patch them in Ubuntu to test smaller values.

Should redirecting stdout affect stderr?

Please take a look at this simple Color.go

The last two lines are from os.Stderr, and they will loose color when redirecting stdout:

Is it controlled by the OS or by the color package?

Thx!