Bug#751828: pcre3: FTBFS [ppc64el]: Test failure in common with amd64
Thanks for the patch. In fact I was intending to do an upload yesterday, and held off when I saw this message. Looking at the bugs you filed on PCRE and glib (thanks), it looks like I should go ahead with a pcre 8.35 release, and glib will have to deal with this, do you agree? On 20 Jul 2014, at 18:56, Simon McVittie s...@debian.org wrote: On Sun, 20 Jul 2014 at 16:07:06 +0100, Simon McVittie wrote: This was already reported as http://bugs.exim.org/show_bug.cgi?id=1463 and fixed upstream as part of r1472. However, the upstream fix did not update the expected output, so the tests still fail. The upstream fix did in fact update the expected output, I just wasn't paying enough attention to the other contents of the svn commit. I plan to do a delayed NMU soon with the attached changes, if the maintainer doesn't upload first. However, I haven't done so yet, because the updated pcre3 seems to trigger a test failure in the pcre consumer I'm mainly interested in (GLib), and I want to be sure that these changes aren't what's to blame for that. Thanks, S pcre3-nmudiff-751828.diff -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686495: libpcre3: Very large value for re_nsub
The patch has now been accepted by upstream and will be in the next release. http://bugs.exim.org/show_bug.cgi?id=1287 I'm happy to include it in the debian package before that, and will do when I get time in the next week. On 2 Sep 2012, at 12:35, Patrick Häcker wrote: Package: libpcre3 Version: 1:8.30-5 Severity: grave Tags: patch Justification: causes non-serious data loss Dear Maintainer, when compiling the regular expression regex_t rx; regcomp(rx, ^(\\(\\))? *(.*)$, 0) I get the large value 140733193388034 for rx.re_nsub. As this value is often used afterwards in malloc this normally leads to the termination of the programm (either because of the segfault or due to the assumption of no free memory), so unsaved data gets lost. The problem is well known (http://www.exim.org/lurker/message/20120822.143744.147fd5d2.de.html) and a patch exists (http://bugs.exim.org/attachment.cgi?id=586). I can confirm that the patch works. Please consider applying the patch. Cheers Patrick -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-proposed-updates'), (500, 'stable-updates'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/6 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpcre3 depends on: ii libc6 2.13-35 ii multiarch-support 2.13-35 libpcre3 recommends no packages. libpcre3 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664983: Version
Since someone has released an 8.30.really8.12-1.1 version, I'm going to released the fixed version as 8.30..-2, as that sorts correctly after 8.30.really8.12-1.1 and before 8.31-1. What would have been wrong with 8.30-1.really.8.12.1 which would have let me replace it with a proper 8.30 version easily? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664983: pcre3 #664983
On Thu, March 22, 2012 12:44 pm, Torsten Wohlfarth wrote: EXTRA_LIBPCRE_LDFLAGS=$EXTRA_LIBPCRE_LDFLAGS \ - - $NO_UNDEFINED -version-info 1:0:0 + $NO_UNDEFINED -version-info 16:1:13 Thanks. Actually I knew what the problem was as soon as I saw the bug report. I updated the last number but should have updated the first one too. There are many reasons I hate libtool but the obscurity of the version numbering system is definitely on the list. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664983: closed by Mark Baker m...@mnb.org.uk (Bug#664983: fixed in pcre3 8.30..-2)
In personal email, Hector Oron wrote: There were more files with wrong SONAME. I assume you have verified it. There were two libraries that were wrong, and I fixed the only two places that had a version number set, so I assumed it was all fixed, but I only checked libpcre.so.3. After I got your email I checked the other one, and it was still wrong. This was a different bug - the version number was not set on libpcreposix.so at all, but was wrongly set on the 16 bit version of libpcre.so, which doesn't get built at all. This is because I applied the diff manually (it didn't work automatically) and got it wrong. I doubt anyone would ever have noticed, I don't think anyone uses libpcreposix I've now uploaded a version which fixes this. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581202: libpcre3 8.02-1 causes approx/stable to segfault
On 11/05/2010 15:59, Lucas Nussbaum wrote: Upgrading libpcre3 from version 7.8-3 (in testing) to version 8.02-1 (in unstable) causes approx 3.3.0 (in stable) to start segfaulting at startup (on amd64). It works OK on i386. The version in unstable works on both. Although I can reproduce this easily, I'm not sure how to go about tracking down the problem. There are no debugging symbols in the released binary so gdb doesn't reveal much. When I built approx 3.3.0 from source, it worked (or at least didn't crash on startup, I didn't try to install it). pcre_config(0, 0x7fffd014, 57, 0x7f7e6fb36900, 0x7fffcf40) = 0 pcre_config(1, 0x7fffd014, -84616, 0x7f7e6fb36900, 0x7fffcf40) = 0 pcre_config(2, 0x7fffd014, -84632, 0x7f7e6fb36900, 0x7fffcf40) = 0 pcre_config(4, 0x7fffd014, -84584, 0x7f7e6fb36900, 0x7fffcf40) = 0 Which returned OK, so it didn't crash in these functions. I'm not sure what ltrace outputs if a signal is received during a library call, does it output anything for the library call at all? i.e. could there be another pcre function called after these ones, which ltrace hasn't output anything for because of the seg fault? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#465676: I have the same bug with subtitleeditor (0.20.0)
Anibal Avelar wrote: Some users has gone this message: $ subtitleeditor subtitleeditor: symbol lookup error: subtitleeditor: undefined symbol: _ZN7pcrecpp6no_argE I think the problem is exactly the same described on this bug. The users had the version 7.4-1+lenny1 and 7.6-1, but I can't reproduce it. I don't know if the last version 7.6-2 to fix the problem. That looks like the same problem, and 7.6-2 should fix it. I suppose if you wanted to be sure you could downgrade pcre on your system and see if you can reproduce the fault that way, but with that error message I'm fairly sure it's the same problem. The problem was marked how grave, but I'm thinking to reassign the bug to the libpcre3 package. If you do, I'll immediately close it, as it's a duplicate of this and so is already fixed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464320: Request for binNMUs for libpcre3 [Fwd: Bug#463413: problem solved by recompiling the package !]
On Wed, Feb 06, 2008 at 06:54:47PM +0100, Andreas Metzler wrote: It simple rebuild would still break partial upgrades. Yes, I agree. I don't think rebuilding the reverse dependencies is the right solution. The changelog suggests that the ABI change is un-necessary (it was an attempt to fix a problem on windows). We could just revert the change, but that would mean we had a different ABI from other distributions. I'm not sure what the best solution is here. What if anything have other distros done? Is it clear at all yet whether the ABI breakage is in the C++ wrapper libpcrecpp0 or in the main library? Yes, it's in the C++ wrapper. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436210: This bug was not marked closed by 7.3-2 upload
On Wed, Sep 19, 2007 at 03:51:14AM +0300, Touko Korpela wrote: Your pcre3 (7.3-2) upload used wrong syntax for bug closing in changelog. I assume the problem is the line break in the middle? Perhaps debian-changelog-mode.el needs to be enhanced so it won't put one there. Anyway, I've now closed the bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436277: pcregrep: unknown option bit(s) set
Carl Fürstenberg wrote: Everytime I tries to use pcregrep, it just fails telling: pcregrep: Error in command-line regex at offset 0: unknown option bit(s) set It works fine for me: p4-7088:~grep power.*wait /etc/inittab pf::powerwait:/etc/init.d/powerfail start po::powerokwait:/etc/init.d/powerfail stop p4-7088:~dpkg -l pcregrep Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii pcregrep 7.2-1 grep utility that uses perl 5 compatible reg p4-7088:~ Please send me the input you used to get the error message and I will investigate. Until then there's not a lot I can do. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329759: I have this problem
I've got a sarge/testing system, and tried to upgrade to lenny this week, but ran into exactly this problem. Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400121: Can't reproduce 400121 with libpcre3
On Wed, Nov 29, 2006 at 12:59:47PM +0100, Tom Parker wrote: I've just been doing the test that Olivier Trichet mentioned with pcretest, with a file containing 30,000 Z's, and I don't get a crash. This is with libpcre3 6.7-1 on i386. I can reproduce it with pcregrep; no idea why pcretest might not suffer from it. It crashes when it gets to 8192 recursive instances of the match function, possibly due to running out of stack space? You are looking for a pattern of (.)* I assume? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400121: Can't reproduce 400121 with libpcre3
On Wed, Nov 29, 2006 at 03:49:02PM +0100, Tom Parker wrote:
about my system... where exactly does pcregrep crash? A stack trace
would be nice.
p4-7088:~for i in $(seq 1 8192); do echo -n Z file; done
p4-7088:~pcregrep '(.)*' file
Segmentation fault
Running it under gdb, using the copy in the build tree (as the installed
version is stripped):
(gdb) run '(.)*' /home/mark/file
Starting program: /home/mark/debian/pcre/pcre3-6.7/.libs/pcregrep '(.)*'
/home/mark/file
Program received signal SIGSEGV, Segmentation fault.
match (eptr=0xbfff842d 'Z' repeats 200 times..., ecode=0x804df0f \vC,
offset_top=4, md=0xbfff72f8, ims=0, eptrb=0xbf800644, flags=2, rdepth=8156)
at ./pcre_exec.c:378
378 {
(gdb) bt
#0 match (eptr=0xbfff842d 'Z' repeats 200 times..., ecode=0x804df0f \vC,
offset_top=4, md=0xbfff72f8, ims=0, eptrb=0xbf800644, flags=2, rdepth=8156)
at ./pcre_exec.c:378
#1 0x40029014 in match (eptr=value optimized out,
ecode=value optimized out, offset_top=value optimized out,
md=0xbfff72f8, ims=0, eptrb=0xbf800644, flags=value optimized out,
rdepth=8155) at ./pcre_exec.c:629
#2 0x400255b7 in match (eptr=0xbfff842d 'Z' repeats 200 times...,
ecode=value optimized out, offset_top=4, md=0xbfff72f8, ims=0,
eptrb=0xbf800e44, flags=value optimized out, rdepth=8154)
at ./pcre_exec.c:1190
#3 0x40029014 in match (eptr=value optimized out,
ecode=value optimized out, offset_top=value optimized out,
md=0xbfff72f8, ims=0, eptrb=0xbf800e44, flags=value optimized out,
rdepth=8153) at ./pcre_exec.c:629
#4 0x400255b7 in match (eptr=0xbfff842d 'Z' repeats 200 times...,
ecode=value optimized out, offset_top=4, md=0xbfff72f8, ims=0,
eptrb=0xbf801644, flags=value optimized out, rdepth=8152)
at ./pcre_exec.c:1190
and so on for thousands more calls to match(), with alternating calling
addresses. Where it's actually failed is right at the beginning of the
function, before it's got to any code. Looks like a stack overflow?
Ah, yes, if I use ulimit to make my stack size unlimited it works as
expected. (presumably that's what's different about your system).
I don't think there's a bug here. Using lots of stack space for a
pattern like this is not unreasonable, and dying horribly when you run
out is something you don't get a whole lot of control over.
There is a limit recursion feature of PCRE, which the calling program
could use.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377295: exim: db_upgrade error during configuration
severity 377295 normal thanks Marc Haber wrote: On Fri, Jul 07, 2006 at 02:32:04PM -1000, Ryo Furue wrote: bash# dpkg-reconfigure exim db_upgrade: /var/spool/exim/db/retry.lockfile: unrecognized file type db_upgrade: DB-upgrade: /var/spool/exim/db/retry.lockfile: Invalid argument bash# I marked this bug as grave but I actually don't know how severe this error is. All I can say is that exim *seems* to continue to be working, but . . . This is the usual berkeley DB foo. Try moving /var/spool/exim/db away, creating an empty directory, and see whether this helps. Not entirely. There's a bug here that it tries to check all files in the directory, including the lockfile. I ought to write a more complicated pattern so it ignores lock files. However, there shouldn't ordinarily be a lock file there as exim isn't running - something must have crashed and left it perhaps? All errors from the database upgrade are ignored, so this will have no effect on whether exim runs properly, so this is not really a problem. However the error message sounds bad, so this will confuse people and ought to be fixed. I will do something about it if and when I do another exim package. And, please take a look at the new Description of the exim 3 package, consider that it might disappear from Debian any time soon, and update to exim4. I second this excellent advice. Despite maintaining the exim 3 packages, I have run exim4 on my own server for years. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339250: libstdc++ allocator change
Adeodato Simó wrote: please find a patch at http://people.ubuntu.com/patches/c2a-pcre3.diff Mark, please don't use that patch. The libpcre3 package ships both a C library and a C++ library, and only the C++ one is affected by this libstdc++ change. That's why I haven't done anything about this yet. Given the high number of libpcre3 reverse dependencies (116), Very few of which use the C++ library, of course. it's very unadvisable to rename the whole package. The right course of action would be to ship the C++ library in a separate package, so that in can be independently renamed in further transitions. So I should put the C++ library in a new package, and no longer include it in the libpcre3 package. What should I do about dependencies to get a smooth upgrade path? Obviously people installing new versions of things that use the C++ library will get the new package; until they do isn't there a danger that they will install the new libpcre3 and things will stop working? Mark, please let us know if you'll be able to fix this bug yourself in the next days, so that other libraries depending on libpcre3 can transition themselves. I should have some time at the weekend. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324531: pcre3: CAN-2005-2491
On Mon, Aug 22, 2005 at 06:15:53PM +0200, Adrian Bunk wrote: It should be checked which of the versions in unstable/testing, stable and oldstable might be affected by CAN-2005-2491 (PCRE Heap Overflow May Let Users Execute Arbitrary Code). I'm away on business until wednesday night; if anything needs doing urgently it would be good if someone else could deal with it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318725: libpcre3-dev: Cannot be installed (wrong dependency)
Helge Kreutzmann wrote: The following packages have unmet dependencies: libpcre3-dev: Depends: libpcre3 (= 4.5-1.2) but 5.0-1 is to be installed E: Broken packages It is built to depend on the same version as the library that's built at the same time. I therefore uploaded library and -dev packages of 4.5-1.2 together, and of 5.0-1 together. If somehow 5.0 of the library had got into sarge but the same version of the -dev package hadn't, that would clearly be a bug, but not anything to do with me. However, this doesn't appear to be the case. As far as I can see sarge contains 4.5-1.2 of both, and unstable contains 5.0-1 of both. How you have ended up with 5.0-1 of the library on your system I don't know. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309606: [ia64] FTBFS: testsuite failure
Luk Claes wrote: Relevant snippet of the build log [1]: ./RunTest: line 111: 25459 Bus error ./pcretest -i $testdata/testinput2 testtry make[1]: *** [runtest] Error 1 I can't reproduce this. I've logged in to merulo.debian.org, got the latest source using apt-get, and built it, without any problems. That second test does give some errors about unaligned accesses: lt-pcretest(19487): unaligned access to 0x6fffbaec, ip=0x200498a0 lt-pcretest(19487): unaligned access to 0x6fffbaec, ip=0x200498a0 lt-pcretest(19487): unaligned access to 0x6fffbaec, ip=0x200498a0 lt-pcretest(19487): unaligned access to 0x6fffbaec, ip=0x200498a0 Are these the same problem, that for some reason causes a bus error when the build daemon does it but is caught and just gives an error message here? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
