Skip Menu |
 

This queue is for tickets about the File-MMagic CPAN distribution.

Report information
The Basics
Id: 94716
Status: new
Priority: 0/
Queue: File-MMagic

People
Owner: Nobody in particular
Requestors: nick [...] ccl4.org
Cc:
AdminCc:

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



X-RT-Interface: Web
MIME-Version: 1.0
Message-ID: <rt-4.0.18-16815-1397478304-351.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
X-RT-Original-Encoding: utf-8
Content-Type: multipart/mixed; boundary="----------=_1397478304-16815-2"
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: binary
Content-Length: 1787
Download (untitled) / with headers
text/plain 1.7k
I consider this bug critical, because it results in File::MMagic returning silently the wrong answer "at random" (ie non-deterministic) The basic usage of File::MMagic->new() with no parameters is broken, as soon as the program instantiates a second (or third) File::MMagic object. This scenario is likely if more than one module uses File::MMagic, and caches the object for re-use. Specifically, the code to lazily read from DATA is not robust. It basically can't be. The implementation shares the same DATA file handle between all created File::MMagic objects, but the data handle only has one seek position. Hence if one object is used to make a call to (say) checktype_filename(), and that call advances the data handle (but does not hit EOF) then a call to checktype_filename() made on a second object will not see the entire Magic database, and hence give wrong results. Test case: #!/usr/bin/perl -w use strict; use Test::More; use File::MMagic; my $imgfile = 'cpan.png'; my $textfile = $0; my $fm1 = File::MMagic->new(); my $fm2 = File::MMagic->new(); # Third test fails: is($fm1->checktype_filename($imgfile), 'image/png'); is($fm1->checktype_filename($textfile), 'text/plain'); is($fm2->checktype_filename($imgfile), 'image/png'); # but comment out the two uses of $fm1, and the remaing test starts passing. __END__ output is ok 1 ok 2 not ok 3 # Failed test at mmagic_caching_fail.t line 17. # got: 'application/octet-stream' # expected: 'image/png' 1..3 # Looks like you failed 1 test of 3. I'm not sure what the best fix is. I'd be tempted to eliminate the lazy-reading from the case of ->new(), read <DATA> eagerly, cache the generated array in a file lexical, and then share it between all objects generated with default arguments to new().
Subject: cpan.png
MIME-Version: 1.0
Content-Type: image/png; name="cpan.png"
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline; filename="cpan.png"
Content-Transfer-Encoding: base64
Content-Length: 4282
Download cpan.png
image/png 4.1k
cpan.png


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.