leveldb.Open() causes to stop writing to file

[cjosephson]

What steps will reproduce the problem?

1. log.SetOutput(io.MultiWriter(f, os.Stdout))
2. log some stuff, shows up in file f
3. open database: levigo.Open(dbName, dbOpts)
   4.) log some more stuff, but now it doesn't show up in file f

What is the expected output? What do you see instead?
logging should continue after the db is opened, but it doesn't.
There is a workaround, where you can call log.SetOutput() again just after leveldb.Open() and logging resumes.

What version of the product are you using? On what operating system?
go 1.2.1 on amd64 ubuntu 14.04, with leveldb from github on 04/28/14 (sorry, commit # missing as the files were copied to a new repo)

[jmhodges]

Hm, please provide a code sample demonstrating this. (I'm very much inclined to believe this is not the case but am willing to look at a reproduction!)

[jmhodges]

If you're wondering why I'm skeptical, it's because Open is a very obvious and simple function without magic in it.

If you've got a copy of levigo in your own repo, I'm inclined to suspect there were edits made in it that are not in the original.

The definition of Open is very, very simple with no mention of log, much less log.SetOutput:

levigo/db.go

Line 74 in a00f670

func Open(dbname string, o *Options) (*DB, error) {

[cjosephson]

I think its probably irrelevant how simple your Open function is, and
whether or not you use logging. It seems more likely that its a conflict
between how C++ handles file descriptors and how go does, rather than a
go-specific bug.

This is the code with issues, but it is very complex and I don't have time
to pare it down to a simpler example for you for a few days:
https://github.com/pranjalv123/mexos/tree/master/src

On Thu, May 8, 2014 at 11:31 PM, Jeff Hodges notifications@github.comwrote:

If you're wondering why I'm skeptical, it's because Open is a very obvious
and simple function without magic in it.

If you've got a copy of levigo in your own repo, I'm inclined to suspect
there were edits made in it that are not in the original.

I'm skeptical because the definition of Open is very, very simple with no
mention of log, much less log.SetOutput:

levigo/db.go

Line 74 in a00f670

func Open(dbname string, o *Options) (*DB, error) {

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/23#issuecomment-42630431
.

Colleen Josephson
http://www.cjosephson.net
Dept. of Electrical Engineering and Computer Science
Massachusetts Institute of Technology

[cjosephson]

And I'm not implying you should dig to debug it, but I figured I'd post
this very frustrating issue in case anybody else ever has the same type of
issue.

On Thu, May 8, 2014 at 11:58 PM, Colleen Josephson cjoseph@mit.edu wrote:

I think its probably irrelevant how simple your Open function is, and
whether or not you use logging. It seems more likely that its a conflict
between how C++ handles file descriptors and how go does, rather than a
go-specific bug.

This is the code with issues, but it is very complex and I don't have time
to pare it down to a simpler example for you for a few days:
https://github.com/pranjalv123/mexos/tree/master/src

On Thu, May 8, 2014 at 11:31 PM, Jeff Hodges notifications@github.comwrote:

If you're wondering why I'm skeptical, it's because Open is a very
obvious and simple function without magic in it.

If you've got a copy of levigo in your own repo, I'm inclined to suspect
there were edits made in it that are not in the original.

I'm skeptical because the definition of Open is very, very simple with no
mention of log, much less log.SetOutput:

levigo/db.go

Line 74 in a00f670

func Open(dbname string, o *Options) (*DB, error) {

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/23#issuecomment-42630431
.

Colleen Josephson
http://www.cjosephson.net
Dept. of Electrical Engineering and Computer Science
Massachusetts Institute of Technology

Colleen Josephson
http://www.cjosephson.net
Dept. of Electrical Engineering and Computer Science
Massachusetts Institute of Technology

[jmhodges]

Definitely willing to believe even if we don't agree about how C++ and Go treat OS file descriptors. In any case, we just need a repro.

Another alternate hypothesis: another goroutine is racing on the SetOutput or similar. In fact, I see 8 different places where SetOutput is used in that repo. This isn't recommended usage of the log API. SetOutput is global for everyone and meant to be called just once at boot. An alternative is to pass in a logging object to the things that need it.

I'm going to close this. If you're able to provide a reproduction, please feel free to reopen.