latest cvs dumps core (on OpenBSD) before finished

[GoogleCodeExporter]

What steps will reproduce the problem?
1. process a BAF file with at least 66,000 records

What is the expected output? What do you see instead?

Starting in SVN after 2009-11-19, bafprp dumps core before completing
multiple baf files.  Failure seems to happen between 65,000 and 69,000
record count (in the samples I tried).

Processing these records with an older version succeeds, and I don't see
anything unusual about the records before and after failure point.

What version of the product are you using? On what operating system?

Latest svn (2009-12-03).  OpenBSD 4.6

Please provide any additional information below.

Also, the trailing delimiter is still there.

Original issue reported on code.google.com by th...@bendtel.net on 3 Dec 2009 at 10:30

[GoogleCodeExporter]

I am going to need some more info from bafprp.

I know this is asking for a bit of time, but could you run bafprp in trace mode
(-vvvvv) and paste the last few lines at the bottom of the log?

Alternatively, try setting it in just debug mode -vvvv and see if the error is
recorded there. 

Trace mode will take ages to complete, I would guess it might take 2 or 3 hours 
to do
66,000 records, but I do need to know what was going on.

Original comment by charless...@gmail.com on 3 Dec 2009 at 11:11

• Changed state: Accepted
• Added labels: OpSys-Linux, Priority-Critical, Usability
• Removed labels: Priority-Medium

[GoogleCodeExporter]

It's not asking a lot at all.  I'm extremely appreciative that you are taking 
the
time to get these things fixed so quickly.  You may not be aware, but older 
versions
of bafview are apparently not going to work for records in 2010.

I'm going to attach what looks like the last record in the -vvvvv output.  It 
never
gets to output the record.

Original comment by th...@bendtel.net on 4 Dec 2009 at 5:25

Attachments:

• vvvvv_output.txt

[GoogleCodeExporter]

Thank you for this, I can tell that it is most likely crashing while parsing 
out the
date. 
This is probably thanks to some special code I recently added to make the 
transition
to 2010 easier.

Problem with bafview was that it hard coded in the year 2000 as the only decade 
it
could possibly run in.  I guess the original writer did not think his app would 
last
so long.
Baf files only store the year as a single digit, so bafprp looks up the current
decade to figure out what the other 3 digits are.

There was a potential problem for those users who might want to parse 2009 
files in
2010 so I wrote some auto adjusting code.  Seems this code is not behaving.

Thanks

Original comment by charless...@gmail.com on 4 Dec 2009 at 5:39

[GoogleCodeExporter]

I was not able to reproduce your exact problem, but I did find a nasty memory 
leak
that I just commited a fix for.  
It may just be that your machine ran out of memory thank to the leak.  Try 
running
your pri's again, I am confident the issue is resolved.

Original comment by charless...@gmail.com on 10 Dec 2009 at 4:33

• Changed state: Fixed

[GoogleCodeExporter]

SVN as of 2009-12-10 doesn't appear to have this problem anymore.  Thanks!

Original comment by th...@bendtel.net on 11 Dec 2009 at 12:14

[GoogleCodeExporter]

great!  Glad we got that leak fixed before I make the new release.

Original comment by charless...@gmail.com on 11 Dec 2009 at 12:28

• Changed state: Verified