Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ParsePgsql exception (slice bounds out of range) #157

Closed
abulimov opened this issue Jun 8, 2015 · 3 comments
Closed

ParsePgsql exception (slice bounds out of range) #157

abulimov opened this issue Jun 8, 2015 · 3 comments
Assignees
@monicasarbu
Labels
bug

Comments

@abulimov
Copy link

abulimov commented Jun 8, 2015

Hi, we are trying 1.0-beta1 and getting errors with Postgres 9.3.5:

log_unix.go:123: ERR  ParsePgsql exception. Recovering, but please report this: runtime error: slice bounds out of range.
log_unix.go:124: ERR  Stacktrace: /home/vagrant/src/github.com/elastic/packetbeat/Godeps/_workspace/src/github.com/elastic/libbeat/logp/log_unix.go:124 (0x4662f2)
/usr/local/go/src/runtime/asm_amd64.s:401 (0x42fc35)
/usr/local/go/src/runtime/panic.go:387 (0x41c9a8)
/usr/local/go/src/runtime/panic.go:18 (0x41bb8e)
/home/vagrant/src/github.com/elastic/packetbeat/protos/pgsql/pgsql.go:506 (0x4ebfd3)
/home/vagrant/src/github.com/elastic/packetbeat/protos/pgsql/pgsql.go:671 (0x4ed1df)
/home/vagrant/src/github.com/elastic/packetbeat/protos/tcp/tcp.go:80 (0x4f80a1)
/home/vagrant/src/github.com/elastic/packetbeat/protos/tcp/tcp.go:168 (0x4f9058)
/home/vagrant/src/github.com/elastic/packetbeat/protos/tcp/tcp.go:328 (0x4fb11d)
/home/vagrant/src/github.com/elastic/packetbeat/sniffer/sniffer.go:316 (0x509615)
/home/vagrant/rpmbuild/BUILD/packetbeat/main.go:235 (0x408866)
/usr/local/go/src/runtime/asm_amd64.s:2232 (0x431d71)
log_unix.go:123: ERR  ParsePgsql exception. Recovering, but please report this: runtime error: slice bounds out of range.
log_unix.go:124: ERR  Stacktrace: /home/vagrant/src/github.com/elastic/packetbeat/Godeps/_workspace/src/github.com/elastic/libbeat/logp/log_unix.go:124 (0x4662f2)
/usr/local/go/src/runtime/asm_amd64.s:401 (0x42fc35)
/usr/local/go/src/runtime/panic.go:387 (0x41c9a8)
/usr/local/go/src/runtime/panic.go:18 (0x41bb8e)
/home/vagrant/src/github.com/elastic/packetbeat/protos/pgsql/pgsql.go:506 (0x4ebfd3)
/home/vagrant/src/github.com/elastic/packetbeat/protos/pgsql/pgsql.go:671 (0x4ed1df)
/home/vagrant/src/github.com/elastic/packetbeat/protos/tcp/tcp.go:80 (0x4f80a1)
/home/vagrant/src/github.com/elastic/packetbeat/protos/tcp/tcp.go:168 (0x4f9058)
/home/vagrant/src/github.com/elastic/packetbeat/protos/tcp/tcp.go:328 (0x4fb11d)
/home/vagrant/src/github.com/elastic/packetbeat/sniffer/sniffer.go:316 (0x509615)
/home/vagrant/rpmbuild/BUILD/packetbeat/main.go:235 (0x408866)
/usr/local/go/src/runtime/asm_amd64.s:2232 (0x431d71)

While error says Recovering, packetbeat stops producing any data to Elasticsearch.

I've recordeded a trace as described here, and sent it to tudor@elastic.co.
@tsg tsg added the bug label Jun 8, 2015
@tsg tsg self-assigned this Jun 8, 2015
@monicasarbu monicasarbu assigned monicasarbu and unassigned tsg Jun 11, 2015
monicasarbu added a commit that referenced this issue Jun 11, 2015
@monicasarbu
Make sure the length is big enough (#157)
667c2a8 
As the length from the postgresql command (type + length + message)
includes the size of itself, meaning sizeof(int32) + length(message),
make sure the length is greater than sizeof(int32).
@monicasarbu
Copy link
Contributor

I fixed the particular exception that was happening when a pgsql command was invalid. But the actual reason is that the maximum number of bytes captured per packets is too small. To solve the issue, I recommend to add snaplen: 65535 under the interfaces section.

  interfaces:
    device: any
    snaplen: 65535

@abulimov
Copy link
Author

Thanks for the fix. The documentation for snaplen now says that "You generally want to set this to the MTU size used in your network." Maybe you could add some information about reasons to set such big values as 65536? Thanks in advance!

@tsg
Copy link
Contributor

tsg commented Jun 11, 2015

Yes, it seems that trying to correlate the snaplen with the MTU was a mistake. See more in #155. We'll update the docs as part of that ticket.

tsg pushed a commit to tsg/beats that referenced this issue Jan 20, 2016
@monicasarbu
Make sure the length is big enough (elastic#157)
f57816f 
As the length from the postgresql command (type + length + message)
includes the size of itself, meaning sizeof(int32) + length(message),
make sure the length is greater than sizeof(int32).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@monicasarbu monicasarbu

Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@tsg @abulimov @monicasarbu