Bug 1225 - Objects/stringobject.c:3518: bad argument to internal function
Summary: Objects/stringobject.c:3518: bad argument to internal function
Status: RESOLVED WONTFIX
Alias: None
Product: Mercurial
Classification: Unclassified
Component: Mercurial (show other bugs)
Version: unspecified
Hardware: All All
: normal bug
Assignee: Bugzilla
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-16 06:34 UTC by mattias hellstrom
Modified: 2012-05-13 05:01 UTC (History)
4 users (show)

See Also:
Python Version: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mattias hellstrom 2008-07-16 06:34 UTC
workdir/var/log/php.log looks normal, and I can revert, diff etc old revisions 
of the file. Is there a way to easily fix the repo? I use hg to trace system 
changes so the repo is not very important.

[root@computer backups]# hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
unpacking file workdir/var/log/php.log 9f0811361de9: Objects/
stringobject.c:3518: bad argument to internal function
1563 files, 103 changesets, 5165 total revisions
1 integrity errors encountered!

[root@computer backups]# hg commit -m "daily autocommit" --user root
** unknown exception encountered, details follow
** report bug details to http://www.selenic.com/mercurial/bts
** or mercurial@selenic.com
** Mercurial Distributed SCM (version 0.9.3)
Traceback (most recent call last):
  File "/usr/bin/hg", line 12, in ?
    commands.run()
  File "/usr/lib64/python2.4/site-packages/mercurial/commands.py", line 3000, 
in run
    sys.exit(dispatch(sys.argv[1:]))
  File "/usr/lib64/python2.4/site-packages/mercurial/commands.py", line 3223, 
in dispatch
    return d()
  File "/usr/lib64/python2.4/site-packages/mercurial/commands.py", line 3182, 
in <lambda>
    d = lambda: func(u, repo, *args, **cmdoptions)
  File "/usr/lib64/python2.4/site-packages/mercurial/commands.py", line 454, in 
commit
    force_editor=opts.get('force_editor'))
  File "/usr/lib64/python2.4/site-packages/mercurial/localrepo.py", line 720, 
in commit
    new[f] = self.filecommit(f, m1, m2, linkrev, tr, changed)
  File "/usr/lib64/python2.4/site-packages/mercurial/localrepo.py", line 637, 
in filecommit
    return fl.add(t, meta, transaction, linkrev, fp1, fp2)
  File "/usr/lib64/python2.4/site-packages/mercurial/filelog.py", line 58, in 
add
    return self.addrevision(text, transaction, link, p1, p2)
  File "/usr/lib64/python2.4/site-packages/mercurial/revlog.py", line 994, in 
addrevision
    return self._addrevision(text, transaction, link, p1, p2, d, ifh, dfh)
  File "/usr/lib64/python2.4/site-packages/mercurial/revlog.py", line 1014, in 
_addrevision
    prev = self.revision(self.tip())
  File "/usr/lib64/python2.4/site-packages/mercurial/revlog.py", line 919, in 
revision
    bins.append(self.chunk(r, df=df))
  File "/usr/lib64/python2.4/site-packages/mercurial/revlog.py", line 875, in 
chunk
    return decompress(self.chunkcache[1][offset:offset + length])
  File "/usr/lib64/python2.4/site-packages/mercurial/revlog.py", line 66, in 
decompress
    if t == 'x': return zlib.decompress(bin)
SystemError: Objects/stringobject.c:3518: bad argument to internal function
transaction abort!
rollback completed
Comment 1 Matt Mackall 2008-07-16 09:14 UTC
We've never seen this bug before. It appears you've got some invalid zlib data
but it's possible something else is damaged. Can you email a copy of
.hg/store/data/workdir/var/log/php.log.i and .d to mpm at selenic.com?
Comment 2 Matt Mackall 2008-07-17 17:32 UTC
Your repo appears to be intact. I can decompress the first 30 versions of this
file on my laptop in under a second. The last version decompresses to over 1.3G,
and thus drives my laptop deep into swap. After an hour and a half, it's still
dumping out the file, but it has successfully decompressed and its hash has been
verified.

My laptop has 1G of RAM and runs a 64-bit version of Debian. I tried
decompressing the troublesome version on a 64-bit Fedora machine with 16G of RAM
and it managed to blow up in about 5s. A bit of experimenting shows that on
Fedora, Python's zlib is unhappy decompressing any single hunk over 1G. But I
was able to manually decompress the data in two chunks and recombine them.

So this is somehow a bug in the Fedora build of Python. We could work around it
by uncompressing the file delta in chunks, but this would double the memory
requirements - not very nice.
Comment 3 mattias hellstrom 2008-07-19 01:56 UTC
Thanks alot for the investigation.
Comment 4 Dirkjan Ochtman 2008-08-04 09:02 UTC
Setting this to done-cbb as it seems to be a Fedora bug.
Comment 5 Bugzilla 2012-05-12 08:52 UTC

--- Bug imported by bugzilla@serpentine.com 2012-05-12 08:52 EDT  ---

This bug was previously known as _bug_ 1225 at http://mercurial.selenic.com/bts/issue1225