Opened 15 years ago
Closed 15 years ago
#392 closed defect (fixed)
A memory leakage in mondo-2.2.9.1-1
Reported by: | robert lin | Owned by: | Bruno Cornec |
---|---|---|---|
Priority: | normal | Milestone: | 2.2.9.3 |
Component: | mondo | Version: | 2.2.9.1 |
Severity: | normal | Keywords: | |
Cc: |
Description
mondoarchive doesn't work on backing up Windows
A memory leakage occurrs at below line marked as ##. Just delete this could be ok.
src/common/libmondo-archive.c
:
:
default:
log_msg(2,
"feed_into_ntfsprog() called in background --- pid=%ld",
(long int) (pid));
mr_free(sz_devfile); ## delete this line
}
Attachments (3)
Change History (13)
comment:1 by , 15 years ago
Owner: | changed from | to
---|
comment:2 by , 15 years ago
Milestone: | 2.2.9.2 → 2.2.10 |
---|
comment:3 by , 15 years ago
Please check the attachement. I just picked up the error part of the log.
by , 15 years ago
Attachment: | screenmessage.log added |
---|
comment:5 by , 15 years ago
So your real error is *not* a memory leak, but an impossibility to open a device:
Cannot archive bigfile '/dev/sda1': not found
Now, I still need the *full* log file in order to understand what may happen. But with the above message check that you can access /dev/sda1 already.
comment:7 by , 15 years ago
Breakpoint 1, make_slices_and_images (
biggielist_fname=0x8848c70 "/tmp/mondo.scratch.1200/mondo.scratch.2382/archives/biggielist.txt") at libmondo-archive.c:2112[[BR]]
2112 log_msg(2,
(gdb) display ntfsprog_fifo
1: ntfsprog_fifo = 0x88453d0 "/tmp/mondo.tmp.UjKSLQ/8364.441.000"
(gdb) display sz_devfile
2: sz_devfile = 0x88453d0 "/tmp/mondo.tmp.UjKSLQ/8364.441.000"
(gdb) n
2115 mr_free(sz_devfile);
2: sz_devfile = 0x88453d0 "/tmp/mondo.tmp.UjKSLQ/8364.441.000"
1: ntfsprog_fifo = 0x88453d0 "/tmp/mondo.tmp.UjKSLQ/8364.441.000"
(gdb)
2112 log_msg(2,
2: sz_devfile = 0x88453d0 "/tmp/mondo.tmp.UjKSLQ/8364.441.000"
1: ntfsprog_fifo = 0x88453d0 "/tmp/mondo.tmp.UjKSLQ/8364.441.000"
(gdb)
2115 mr_free(sz_devfile);
2: sz_devfile = 0x88453d0 "/tmp/mondo.tmp.UjKSLQ/8364.441.000"
1: ntfsprog_fifo = 0x88453d0 "/tmp/mondo.tmp.UjKSLQ/8364.441.000"
(gdb)
2124 if (IS_THIS_A_STREAMING_BACKUP(bkpinfo->backup_media_type)) {
2: sz_devfile = 0x0
1: ntfsprog_fifo = 0x88453d0 "\b\213\204\b/mondo.tmp.UjKSLQ/8364.441.000"
(gdb)
2130 res =
2: sz_devfile = 0x0
1: ntfsprog_fifo = 0x88453d0 "\b\213\204\b/mondo.tmp.UjKSLQ/8364.441.000"
(gdb)
comment:8 by , 15 years ago
Milestone: | 2.2.10 → 2.2.9.3 |
---|---|
Owner: | changed from | to
Status: | new → assigned |
Ah, sorry, indeed there is an issue !
So sz_devfile is clearly freed too early. What about the proposed patch in rev [2578] ?
comment:10 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I disagree with your analysis. Removing such a line will never allow you to solve a memory *leak* problem. Rather it will create one.
The sz_devfile var is allocated by the mr_asprintf just upper. So it needs to be freed after its usage in the parent.
So what is your problem and could you provide log files please ?