Memory leak in nsCellMap::ExpandWithRows()

RESOLVED INCOMPLETE

Status

()

Core
Layout: Tables
P2
normal
RESOLVED INCOMPLETE
16 years ago
22 days ago

People

(Reporter: Peter A Jonsson, Unassigned)

Tracking

({mlk})

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [whitebox], URL)

(Reporter)

Description

16 years ago
__builtin_new -:- libstdc++-libc6.1-1.so.2 0x407d81e6 
nsCellMap::AppendCell <...> nsCellMap.cpp:1191 libgklayout.so 0x8075dbf3 
nsCellMap::ExpandWithRows <...> nsCellMap.cpp:1425 libgklayout.so 0x8075e59d 
nsCellMap::InsertRows <...> nsCellMap.cpp:1083 libgklayout.so 0x8075d86e 
nsTableCellMap::InsertRows <...> nsCellMap.cpp:440 libgklayout.so 0x8075bdbb

Not catching a return value from AppendCell at nsCellMap.cpp:1425?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mlk

Comment 1

16 years ago
I went to the URL, it does not show this pattern for 2002-04-09.

Comment 2

16 years ago
 WFM on both branch and trunk builds : 2002061408. WIN2K. I am not seeing any 
kind of assertion or memory leak.

Comment 3

16 years ago
 WFM on both branch and trunk builds : 2002061408. WIN2K. I am not seeing any 
kind of assertion or memory leak.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 4

16 years ago
This is a memory leak, not an assertion of any kind. 

Fresh from CVS:

CellData *
nsTableCellMap::AppendCell(..) {
 <..>
 CellData *result;
 <..>
 result = ...
 return result;
}

From line 1424:

  if (IS_TABLE_CELL(cFrameType)) {
    AppendCell(aMap, (nsTableCellFrame *)cFrame, rowX, PR_FALSE, DamageArea);
  }

Why does this *not* leak?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Updated

16 years ago
Priority: -- → P2

Comment 5

16 years ago
Peter, why does it leak? This code is just adding an entry to the cell map if it 
is a cell. If it is not a cell, it doesn't get added, but it still has a frame. 

Comment 6

16 years ago
just for the record: origdata is returned from cellmap::AppendCell if this
pointer is not always added to the cellmap then it would be lost

Updated

15 years ago
Target Milestone: --- → Future

Updated

15 years ago
Whiteboard: [whitebox]

Comment 7

15 years ago
mass reassign to default owner
Assignee: karnaze → table
Status: REOPENED → NEW
QA Contact: amar → madhur
Target Milestone: Future → ---

Updated

15 years ago
Target Milestone: --- → Future
It looks like AppendCell does in fact put the data in the cellmap (except in
cases that assert and should never be hit....).

So I don't think we have a leak here (though we do have some rather unreadable
code).
Assignee: layout.tables → nobody
QA Contact: madhur → layout.tables
Can we close this bug as we shouldn't have a leak here?
Status: NEW → RESOLVED
Last Resolved: 16 years ago22 days ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.