out of memory on commit
I'm getting out of memory error during the commit operation (it stalls for a while showing
'Saving data locally - Stage:repacking texts:texts 14/175') and then aborts.
It's a relatively small repository, and the commit renames 3 files and modifies another 20. Needless to say it had been working perfectly fine for quite some time. I'm running version 2.0.2 on Ubuntu Karmic 32 bits.
Any light on what's going on?
Thanks
Question information
- Language:
- English Edit question
- Status:
- Answered
- For:
- Bazaar Edit question
- Assignee:
- No assignee Edit question
- Last query:
- Last reply:
Related FAQ:
None Link to a FAQ
Revision history for this message
|
#1 |
Can you please post the traceback from ~/.bzr.log, and also the result of running 'bzr info -v' in your branch.
Revision history for this message
|
#2 |
Here it is
>bzr info -v
Standalone tree (format: 2a)
Location:
branch root: .
Related branches:
push branch: sftp://[EDITED]
parent branch: sftp://[EDITED]
Format:
control: Meta directory format 1
working tree: Working tree format 6
branch: Branch format 7
repository: Repository format 2a - rich roots, group compression and chk inventories
In the working tree:
219 unchanged
33 modified
0 added
0 removed
3 renamed
2 unknown
67 ignored
39 versioned subdirectories
Branch history:
59 revisions
78 days old
first revision: Thu 2009-12-10 15:35:19 -0600
latest revision: Fri 2010-02-26 15:18:08 -0600
Repository:
59 revisions
> cat ~/.bzr.log
.
.
.
Fri 2010-02-26 18:55:57 -0600
0.026 bzr arguments: [u'ci', u'-m', u'More meaningful error messages']
0.074 looking for plugins in /home/alejandr/
0.191 looking for plugins in /usr/lib/
0.240 encoding stdout as sys.stdout encoding 'UTF-8'
0.595 opening working tree '/home/
0.630 preparing to commit
[28446] 2010-02-26 18:55:58.119 INFO: Committing to: /home/alejandr/
0.710 Selecting files for commit with filter None
[28446] 2010-02-26 18:55:58.186 INFO: modified build.number
[28446] 2010-02-26 18:55:58.212 INFO: modified src/myproject/
[28446] 2010-02-26 18:55:58.213 INFO: renamed src/myproject/
.
. [EDITED, SEVERAL MORE]
.
.
.
[28446] 2010-02-26 18:55:58.223 INFO: modified src/myproject/
1.139 Auto-packing repository <bzrlib.
1.140 repacking 10 revisions
1.230 repacking 10 inventories
1.236 repacking chk: 10 id_to_entry roots, 5 p_id_map roots, 15 total keys
1.290 repacking 176 texts
5.178 Adding the key (<bzrlib.
44.453 Adding the key (<bzrlib.
52.525 aborting commit write group because of exception:
54.286 Traceback (most recent call last):
File "/usr/lib/
self.rev_id = self.builder.
File "/usr/lib/
self.
File "/usr/lib/
result = self._commit_
File "/usr/lib/
hint = self._pack_
File "/usr/lib/
result = self.autopack()
File "/usr/lib/
return self._do_autopack()
File "/usr/lib/
reload_
File "/usr/lib/
result = packer.pack()
File "/usr/lib/
return self._create_
File "/usr/lib/
self.
File "/usr/lib/
'texts', self._get_
File "/usr/lib/
reuse_
File "/usr/lib/
bytes = record.
File "/usr/lib/
self.
File "/usr/lib/
self.
File "/usr/lib/
self.
MemoryError
[28446] 2010-02-26 18:56:51.772 INFO: aborting commit write group: MemoryError()
60.861 Traceback (most recent call last):
File "/usr/lib/
return the_callable(*args, **kwargs)
File "/usr/lib/
ret = run(*run_argv)
File "/usr/lib/
return self.run(
File "/usr/lib/
exclude=
File "/usr/lib/
result = unbound(self, *args, **kwargs)
File "/usr/lib/
result = WorkingTree3.
File "/usr/lib/
result = unbound(self, *args, **kwargs)
File "/usr/lib/
*args, **kwargs)
File "/usr/lib/
self.rev_id = self.builder.
File "/usr/lib/
self.
File "/usr/lib/
result = self._commit_
File "/usr/lib/
hint = self._pack_
File "/usr/lib/
result = self.autopack()
File "/usr/lib/
return self._do_autopack()
File "/usr/lib/
reload_
File "/usr/lib/
result = packer.pack()
File "/usr/lib/
return self._create_
File "/usr/lib/
self.
File "/usr/lib/
'texts', self._get_
File "/usr/lib/
reuse_
File "/usr/lib/
bytes = record.
File "/usr/lib/
self.
File "/usr/lib/
self.
File "/usr/lib/
self.
MemoryError
60.871 return code 3
Revision history for this message
|
#4 |
Given that nobody else has hit that problem and it's a pretty small commit and repository, I wonder if this has some disk (or sftp) corruption that is making the zlib buffer look unreasonably big.
Could you please try setting
export BZR_PDB=1
then re-run that command; it should put you in a debugger; then type
p num_bytes
p self._content_
p self._z_
Revision history for this message
|
#5 |
This is what i get:
(Pdb) p num_bytes
1013974054
(Pdb) p self._content_
1013974054
(Pdb) p self._z_
'x\x9c\
(Pdb)
'x\x9c\
Revision history for this message
|
#6 |
So it's just a bit over 1GB. It's not particularly a round number and it's plausibly large enough we would have trouble allocating that much memory.
Could you please paste the output of
bzr modified|xargs ls -so
Revision history for this message
|
#7 |
Here it is:
> bzr modified|xargs ls -so
4 -rw------- 1 alejandr 83 2010-03-11 15:55 build.number
4 -rw------- 1 alejandr 64 2010-02-27 18:04 .bzrignore
4 -rw------- 1 alejandr 102 2010-03-11 15:55 src/daffodil/
8 -rw------- 1 alejandr 7585 2010-03-03 13:04 src/daffodil/
4 -rw------- 1 alejandr 618 2010-03-03 10:48 src/daffodil/
4 -rw------- 1 alejandr 270 2010-03-03 10:48 src/daffodil/
4 -rw------- 1 alejandr 288 2010-03-03 10:48 src/daffodil/
4 -rw------- 1 alejandr 285 2010-03-03 10:48 src/daffodil/
4 -rw------- 1 alejandr 288 2010-03-03 10:48 src/daffodil/
4 -rw------- 1 alejandr 297 2010-03-03 10:48 src/daffodil/
4 -rw------- 1 alejandr 303 2010-03-03 10:48 src/daffodil/
4 -rw------- 1 alejandr 313 2010-03-03 10:48 src/daffodil/
4 -rw------- 1 alejandr 222 2010-03-03 10:48 src/daffodil/
20 -rw------- 1 alejandr 19934 2010-03-03 12:51 src/daffodil/
16 -rw------- 1 alejandr 13464 2010-03-03 10:48 src/daffodil/
4 -rw------- 1 alejandr 2615 2010-03-10 15:11 src/daffodil/
12 -rw------- 1 alejandr 9898 2010-03-10 15:42 src/daffodil/
4 -rw------- 1 alejandr 3661 2010-03-10 15:41 src/daffodil/
4 -rw------- 1 alejandr 2070 2010-03-10 15:38 src/daffodil/
4 -rw------- 1 alejandr 1621 2010-03-10 15:40 src/daffodil/
4 -rw------- 1 alejandr 1618 2010-03-10 15:40 src/daffodil/
4 -rw------- 1 alejandr 2952 2010-03-10 15:38 src/daffodil/
4 -rw------- 1 alejandr 1866 2010-03-10 15:39 src/daffodil/
4 -rw------- 1 alejandr 1097 2010-03-10 15:37 src/daffodil/
4 -rw------- 1 alejandr 1621 2010-03-10 15:39 src/daffodil/
4 -rw------- 1 alejandr 719 2010-03-10 15:40 src/daffodil/
24 -rw------- 1 alejandr 20745 2010-03-11 15:54 src/daffodil/
4 -rw------- 1 alejandr 1661 2010-03-03 10:48 src/daffodil/
4 -rw------- 1 alejandr 1320 2010-03-03 10:48 src/daffodil/
4 -rw------- 1 alejandr 188 2010-03-03 10:48 src/daffodil/
12 -rw------- 1 alejandr 10338 2010-03-03 10:48 src/daffodil/
4 -rw------- 1 alejandr 3478 2010-03-03 10:48 src/daffodil/
4 -rw------- 1 alejandr 1417 2010-03-03 10:48 src/daffodil/
8 -rw------- 1 alejandr 5977 2010-03-11 15:27 src/daffodil/
8 -rw------- 1 alejandr 6297 2010-03-11 15:27 src/daffodil/
4 -rw------- 1 alejandr 2820 2010-03-03 10:48 src/daffodil/
8 -rw------- 1 alejandr 4850 2010-03-11 15:27 src/daffodil/
8 -rw------- 1 alejandr 5211 2010-03-10 15:10 src/daffodil/
4 -rw------- 1 alejandr 1206 2010-03-03 10:48 src/daffodil/
4 -rw------- 1 alejandr 2887 2010-03-03 10:48 src/daffodil/
12 -rw------- 1 alejandr 11998 2010-03-10 15:26 src/daffodil/
8 -rw------- 1 alejandr 6124 2010-03-11 15:25 srcTest/
4 -rw------- 1 alejandr 605 2010-03-03 13:33 test/AO002.xml
4 -rw------- 1 alejandr 605 2010-03-03 13:33 test/AO003.xml
4 -rw------- 1 alejandr 1693 2010-03-03 13:14 test/AO.xsd
4 -rw------- 1 alejandr 605 2010-03-11 15:29 test/output.xml
Revision history for this message
|
#8 |
Could you please post a listing, including the sizes, of the pack directory? This is during autopack.
I wonder if we should just stop autopacking once they get to say 500MB in size.
Revision history for this message
|
#9 |
@Poolie, no, we shouldn't - many big packs gives terrible performance, as does many small packs. Repacking is not very expensive on memory, so its not an obvious culprit here.
Revision history for this message
|
#10 |
The backtrace shows that there is a group with 1GB of content in it; we only make groups that big when compressing really big files. Looks like someone has added e.g. a few isos or something.
Can you help with this problem?
Provide an answer of your own, or ask alejandro for more information if necessary.