[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20040401: queue size issue and seg fault.

Stownie,

Without the actual debug information, I could only guess. But, several
things could be happening inside pq_insert, including several things
that would point to either you providing an incorrect size or 
memory area that isn't the expected size in the prod structure being
passed to pq_insert();. Are you inserting unzlib'ed products? If so,
then do you have the correct sizes for the massaged data you are
inserting, rather than the original product? The pointer addresses from
dbx/gdb might show if you have clobbered something.

Steve Chiswell 

>From: Stonie Cooper <address@hidden>
>Organization: Planetary Data, Incorporated
>Keywords: 200404010242.i312gsCT011216

>Steve E.,
>
>I wanted to pass something along that I found when trialing new code we have 
>written for LDM 6.0.14.  This problem may have existed in the 5.2.x, 
>also . . . I guess this is just the first time I have done case testing for 
>OOP requirements on our LDM plugin.
>
>I was running a very small queue . . . 126MB . . . and when I did a 
>pq_insert() of the larger GOES GINI . . . I got a seg fault.  I assumed it 
>was our application . . . and focused thus.
>
>After two days of isolation, gdb/dbx (yes, I realizes that dates me a bit), 
>and testing of our app . . . the killer is the pq_insert() call itself.
>
>For my test, I ran a basic algorithm that Steve Chizwell indicated he used on 
>doing NOAAPort->LDM queue inserts.  All was fine until I hit the two big GOES 
>sectors . . . both which are over 22MB expanded.  Again, my queue was small - 
>126MB.
>
>Once I expanded the queue to > 900MB, the problem went away.
>
>Running a small queue is important in some of our applications, as we have 
>some diskless servers we run LDM on, and the queue is made in ramdisk at boot 
>time.  Even with some of our 2GB boxes, we only keep a queue of 500MB.
>
>I don't mind or object to a failure . . . it's the seg fault I wanted to 
>report (and eliminate).  The desired response would have been an error 
>generated from pq_insert(), indicating failure . . . in our OOP/C++ paradigm, 
>so we could throw an exception and deal with it gracefully.  I have not tried 
>it, but I assume any product that approaches a certain % of the queue size 
>would cause similar.
>
>I'm not very knowledgable with LDM source, but I will be willing to debug 
>further if given some direction - and more importantly, an indication that it 
>would be worthwhile.  Let me know your thoughts.
>-- 
>Stonie R. Cooper
>Planetary Data, Incorporated
>(402) 727-6599
>
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.