GNOME Bugzilla – Bug 143724
xbase content larger than one sheet should go into another sheet
Last modified: 2009-09-25 01:27:00 UTC
[Originally reported as http://bugs.debian.org/252468] From: Markus Schaber <schabios@logi-track.com> Subject: gnumeric: Error messages when importing dbf files Message-Id: <20040603174106.7ee63b09@kingfisher.intern.logi-track.com> Package: gnumeric Version: 1.2.11-1 Severity: normal When importing dbf files, I see lots of the following messages: ** (gnumeric:13379): CRITICAL **: file ../../src/sheet.c: line 2445 (sheet_cell_new): assertion `row < SHEET_MAX_ROWS' failed ** (gnumeric:13379): CRITICAL **: file ../../src/cell.c: line 274 (cell_set_value): assertion `cell != NULL' failed ** (gnumeric:13379): CRITICAL **: file ../../src/sheet.c: line 2445 (sheet_cell_new): assertion `row < SHEET_MAX_ROWS' failed ** (gnumeric:13379): CRITICAL **: file ../../src/cell.c: line 274 (cell_set_value): assertion `cell != NULL' failed Later, when closing gnumeric, ist spits lots of the following messages: Leaking string [-D01P20715] with ref_count=1. Leaking string [+D01P20559] with ref_count=2. Leaking string [-D01N20559] with ref_count=2. Leaking string [-D01P20558] with ref_count=2. Leaking string [+D01N20558] with ref_count=2. Leaking string [-D01N12917] with ref_count=2. Leaking string [+D01P12917] with ref_count=2. Thanks, Markus
From: Markus Schaber <schabios@logi-track.com> Subject: Re: Bug#252468: gnumeric: Error messages when importing dbf files Hi, Ray, On Thu, 3 Jun 2004 18:12:49 +0200 "J.H.M. Dassen (Ray)" <jdassen@debian.org> wrote: > On Thu, Jun 03, 2004 at 17:41:06 +0200, Markus Schaber wrote: > > When importing dbf files, I see lots of the following messages: > > Please provide a dbf file for which this problem is reproducible for > you. I don't know whether I'm allowed to do this because the DBF files are licensed from NavTeq inc., but I'll investigate the issue. It seems that it's not a general problem with NavTeq DBF files, but only the bigger files seem to suffer from this problem (the biggest one, streets dbf, that produced the error messages has about 500 Megabytes :-). Additionally, dbview displays all the files without problems. So maybe the sheer size of the file is enough to kill gnumeric, that seems to correspond with the message "assertion `row < SHEET_MAX_ROWS' failed". I now think that there's a hard-coded size limit of 65536 rows which is not cleanly checked when importing, and so this produces the error messages on import and the leaks on closing. The one that produced the "Leaking string [-D01P20715] with ref_count=1." messages has lots of strings of the sort "-D01P20715" in the second column, the first one contains integers. It has only those colums, but about 128998 rows. The aforementioned streets.dbf has 1394098 rows.
From: "J.H.M. Dassen (Ray)" <jdassen@debian.org> To: 252468@bugs.debian.org Cc: Markus Schaber <schabios@logi-track.com> Subject: Re: Bug#252468: gnumeric: Error messages when importing dbf files On Fri, Jun 04, 2004 at 10:05:22 +0200, Markus Schaber wrote: > I don't know whether I'm allowed to do this because the DBF files are > licensed from NavTeq inc., but I'll investigate the issue. Please do. The gnumeric upstream developers have a policy for dealing with bugreports that require sensitive data to reproduce. > So maybe the sheer size of the file is enough to kill gnumeric, that > seems to correspond with the message "assertion `row < SHEET_MAX_ROWS' > failed". > > I now think that there's a hard-coded size limit of 65536 rows There is, primarily for Excel compatibility reasons. > which is not cleanly checked when importing, That sounds like a reasonable explanation. I'll forward this issue upstream and we'll see what the gnumeric developers have to say about it. > and so this produces the error messages on import and the leaks on > closing. Can you try if the problem goes away when you use a rebuilt gnumeric with SHEET_MAX_ROWS in src/gnumeric.h suitably enlarged? > The one that produced the "Leaking string [-D01P20715] with > ref_count=1." messages has lots of strings of the sort "-D01P20715" in > the second column, the first one contains integers. It has only those > colums, but about 128998 rows. The aforementioned streets.dbf has > 1394098 rows. The leaks are only interesting if they're still there once the real problem is fixed.
For now I've clipped things but it would be trivial to just stuff things into another WorkSheet
Update from the submitter (presumably tested with 1.4.0): I just looked at the problem regarding the large dbf files, and it seems that it is not crashing any more. However, it silently truncates the data at 65536 rows without any warning. The same is when I have 65536 rows and insert an additional one, then the last row is silently dropped. So the behaviour is more stable than before, but it would be better with a warning, as this can lead to silent loss of data (opening a large file, editing, and re-saving will lose the additional rows).
Fixed a while ago in the sense that the sheet just gets more rows as needed.