Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the MongoDB CPAN distribution.

Maintainer(s)' notes

Please don't report bugs here. Please use the MongoDB Perl driver issue tracker instead.

Report information
The Basics
Id: 58500
Status: resolved
Priority: 0/
Queue: MongoDB

People
Owner: Nobody in particular
Requestors: arkadiy [...] mindhole.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Circular data structure in query causes segmentation fault
Date: Thu, 17 Jun 2010 18:34:02 -0400
To: bug-MongoDB [...] rt.cpan.org
From: Arkadiy Kukarkin <arkadiy [...] mindhole.org>
Perl segfaults when a structure with circular references is passed to MongoCollection::query(); To reproduce: #!/usr/bin/perl use MongoDB; my $mcon = MongoDB::Connection->new(); my $md = $mcon->get_database('test'); my $mc = $md->get_collection('test'); my $query = {}; $query->{'q'} = $query; my $cur = $mc->query($query); my @res = $cur->all(); This is v5.10.1 on x86_64-linux-gnu-thread-multi, MongoDB 0.33. The short answer is, obviously, "don't do that", but a more graceful way to handle this would be nice. I actually had (what I assume to be) the same or a related bug come up in production code, which generated the following backtrace: *** glibc detected *** perl: malloc(): memory corruption: 0x0000000004923ce0 *** *** glibc detected *** perl: malloc(): memory corruption: 0x0000000004923cc0 *** ** child 2696 finished (255) ======= Backtrace: ========= ======= Backtrace: ========= /lib/libc.so.6(+0x775b6)[0x7fb41af265b6] /lib/libc.so.6(+0x775b6)[0x7fb41af265b6] /lib/libc.so.6(+0x7b6d8)[0x7fb41af2a6d8] /lib/libc.so.6(+0x7b6d8)[0x7fb41af2a6d8] /lib/libc.so.6(__libc_calloc+0xc4)[0x7fb41af2d424] /lib/libc.so.6(__libc_calloc+0xc4)[0x7fb41af2d424] /usr/lib/libperl.so.5.10(Perl_safesyscalloc+0x7b)[0x7fb41b96975b] /usr/lib/libperl.so.5.10(Perl_safesyscalloc+0x7b)[0x7fb41b96975b] /usr/lib/libperl.so.5.10(PerlIOBuf_get_base+0x2f)[0x7fb41b9f22af] /usr/lib/libperl.so.5.10(PerlIOBuf_get_base+0x2f)[0x7fb41b9f22af] /usr/lib/libperl.so.5.10(PerlIOBuf_write+0x1f2)[0x7fb41b9f38e2] /usr/lib/libperl.so.5.10(PerlIOBuf_write+0x1f2)[0x7fb41b9f38e2] /usr/lib/libperl.so.5.10(Perl_vcroak+0x3d)[0x7fb41b96a6ed] /usr/lib/libperl.so.5.10(Perl_vcroak+0x3d)[0x7fb41b96a6ed] /usr/local/lib/perl/5.10.1/auto/MongoDB/MongoDB.so(+0xaed9)[0x7fb4191b8ed9] /usr/local/lib/perl/5.10.1/auto/MongoDB/MongoDB.so(perl_mongo_bson_to_sv+0x5d)[0x7fb4191b96ed] /usr/local/lib/perl/5.10.1/auto/MongoDB/MongoDB.so(XS_MongoDB__Cursor_next+0x179)[0x7fb4191b4809] /usr/lib/libperl.so.5.10(+0x97e05)[0x7fb41b96ce05] /usr/local/lib/perl/5.10.1/auto/MongoDB/MongoDB.so(+0xaed9)[0x7fb4191b8ed9] /usr/local/lib/perl/5.10.1/auto/MongoDB/MongoDB.so(perl_mongo_bson_to_sv+0x5d)[0x7fb4191b96ed] /usr/local/lib/perl/5.10.1/auto/MongoDB/MongoDB.so(XS_MongoDB__Cursor_next+0x/usr/lib/libperl.so.5.10(Perl_pp_entersub+0x5a5)[0x7fb41b980045] /usr/lib/libperl.so.5.10(Perl_pp_entersub+0x5a5)[0x7fb41b980045] /usr/lib/libperl.so.5.10(perl_run+0x33c)[0x7fb41b9263cc] perl(main+0xec)[0x400d7c] /usr/lib/libperl.so.5.10(perl_run+0x33c)[0x7fb41b9263cc] /lib/libc.so.6(__libc_start_main+0xfd)[0x7fb41aecdc4d] perl[0x400bc9] ======= Memory map: ======== /lib/libc.so.6(__libc_start_main+0xfd)[0x7fb41aecdc4d] perl[0x400bc9] ======= Memory map: ======== 00400000-00401000 r-xp 00000000 08:03 18579737 /usr/bin/perl 00601000-00602000 r--p 00001000 08:03 18579737 /usr/bin/perl 00602000-00603000 rw-p 00002000 08:03 18579737 /usr/bin/perl 02508000-049c2000 rw-p 00000000 00:00 0 [heap] 7fb410000000-7fb410021000 rw-p 00000000 00:00 0 7fb410021000-7fb414000000 ---p 00000000 00:00 0 7fb4159a8000-7fb4159be000 r-xp 00000000 08:03 7413789 /lib/libgcc_s.so.1 7fb4159be000-7fb415bbd000 ---p 00016000 08:03 7413789 /lib/libgcc_s.so.1 7fb415bbd000-7fb415bbe000 r--p 00015000 08:03 7413789 /lib/libgcc_s.so.1 7fb415bbe000-7fb415bbf000 rw-p 00016000 08:03 7413789 /lib/libgcc_s.so.1 7fb415bbf000-7fb415bcc000 r-xp 00000000 08:03 18743629 /usr/local/lib/perl/5.10.1/auto/Params/Validate/Validate.so 7fb415bcc000-7fb415dcb000 ---p 0000d000 08:03 18743629 /usr/local/00400000-00401000 r-xp 00000000 08:03 18579737 /usr/bin/perl 00601000-00602000 r--p 00001000 08:03 18579737 /usr/bin/perl 00602000-00603000 rw-p 00002000 08:03 18579737 /usr/bin/perl 02508000-049c2000 rw-p 00000000 00:00 0 [heap] 7fb410000000-7fb410021000 rw-p 00000000 00:00 0 7fb410021000-7fb414000000 ---p 00000000 00:00 0 7fb4159a8000-7fb4159be000 r-xp 00000000 08:03 7413789 /lib/libgcc_s.so.1 7fb4159be000-7fb415bbd000 ---p 00016000 08:03 7413789 /lib/libgcc_s.so.1 7fb415bbd000-7fb415bbe000 r--p 00015000 08:03 7413789 /lib/libgcc_s.so.1 7fb415bbe000-7fb415bbf000 rw-p 00016000 08:03 7413789 /lib/libgcc_s.so.1 7fb415bbf000-7fb415bcc000 r-xp 00000000 08:03 18743629 /usr/local/lib/perl/5.10.1/auto/Params/Validate/Validate.so 7fb415bcc000-7fb415dcb000 ---p 0000d000 08:03 18743629 /usr/local/lib/perl/5.10.1/auto/Params/Validate/Validate.so 7fb415dcb000-7fb415dcc000 r--p 0000c000 08:03 18743629 /usr/local/lib/perl/5.10.1/auto/Params/Validate/Validate.so 7fb415dcc000-7fb415dcd000 rw-p 0000d000 08:03 18743629 /usr/local/lib/perl/5.10.1/auto/Params/Validate/Validate.so 7fb415dcd000-7fb415dd2000 r-xp 00000000 08:03 18737259 /usr/local/lib/perl/5.10.1/auto/DateTime/DateTime.so 7fb415dd2000-7fb415fd1000 ---p 00005000 08:03 18737259 /usr/local/lib/perl/5.10.1/auto/DateTime/DateTime.so 7fb415fd1000-7fb415fd2000 r--p 00004000 08:03 18737259 /usr/local/lib/perl/5.10.1/auto/DateTime/DateTime.so 7fb415fd2000-7fb415fd3000 rw-p 00005000 08:03 18737259 /usr/local/lib/perl/5.10.1/auto/DateTime/DateTime.so
The best (and not very good) way I can think of for checking this is to call backtrace() after every 10000 key/value pairs are serialized. If we're more than, I dunno, 5000 stackframes deep, croak. Obviously this isn't very elegant, but I think it would work and it shouldn't have too big a performance hit. If anyone has any better ideas, please share!
Subject: Re: [rt.cpan.org #58500] Circular data structure in query causes segmentation fault
Date: Fri, 18 Jun 2010 19:45:53 +0200
To: Kristina Chodorow via RT <bug-MongoDB [...] rt.cpan.org>
From: Florian Ragwitz <rafl [...] debian.org>
On Fri, Jun 18, 2010 at 01:29:34PM -0400, Kristina Chodorow via RT wrote: Show quoted text
> If anyone has any better ideas, please share!
Just tracking the addresses of references as they're being serialized, and throwing an exception when trying to recurse into something that has already been recursed into would be another option. In fact, this sounds much better than limiting the possible depth for non-circular structures to me. -- BOFH excuse #207: We are currently trying a new concept of using a live mouse. Unfortunately, one has yet to survive being hooked up to the computer.....please bear with us.
Download signature.asc
application/pgp-signature 189b

Message body not shown because it is not plain text.

I'm little hesitant to throw all of the addresses in a hash table because there could be millions of values in a legit document, but I guess that's only a few MB.
Subject: Re: [rt.cpan.org #58500] Circular data structure in query causes segmentation fault
Date: Fri, 18 Jun 2010 20:04:38 +0200
To: Kristina Chodorow via RT <bug-MongoDB [...] rt.cpan.org>
From: Florian Ragwitz <rafl [...] debian.org>
On Fri, Jun 18, 2010 at 01:54:05PM -0400, Kristina Chodorow via RT wrote: Show quoted text
> I'm little hesitant to throw all of the addresses in a hash table > because there could be millions of values in a legit document, but I > guess that's only a few MB.
You only need to track reference values, and you can remove the entry for that from whatever you use for tracking as soon as you return from a recursion into it. I can't see this taking an unreasonable amount of memory for any even not-so-common usecase. -- BOFH excuse #325: Your processor does not develop enough heat.
Download signature.asc
application/pgp-signature 189b

Message body not shown because it is not plain text.

Subject: Re: [rt.cpan.org #58500] Circular data structure in query causes segmentation fault
Date: Fri, 18 Jun 2010 15:17:44 -0400
To: bug-MongoDB [...] rt.cpan.org
From: Arkadiy Kukarkin <arkadiy [...] mindhole.org>
Incidentally, the above stack trace is an unrelated issue. Just wanted to clear that up. On Fri, Jun 18, 2010 at 2:04 PM, Florian Ragwitz via RT <bug-MongoDB@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=58500 > > > On Fri, Jun 18, 2010 at 01:54:05PM -0400, Kristina Chodorow via RT wrote:
>> I'm little hesitant to throw all of the addresses in a hash table >> because there could be millions of values in a legit document, but I >> guess that's only a few MB.
> > You only need to track reference values, and you can remove the entry > for that from whatever you use for tracking as soon as you return from a > recursion into it. I can't see this taking an unreasonable amount of > memory for any even not-so-common usecase. > > > -- > BOFH excuse #325: > Your processor does not develop enough heat. > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFMG7UsdC8qQo5jWl4RAqb1AJ9fKU8F88Q4UfV20halPC+shi5FaQCbBe9f > kPsmT2dYvvctqQuk9A3oLNU= > =Uy2N > -----END PGP SIGNATURE----- > >
@Florian: Good point. Added to master, will be in 0.35. Now it croaks with: circular ref at /usr/local/lib/perl5/...