[Pvfs2-developers] failed assert in id_gen_safe_register()

[Sam Lang]

On Sep 10, 2007, at 8:00 AM, Scott Atchley wrote:

> Hi Sam,
>
> Thanks for the heads up. Is it safe to use on both the client and  
> server?

It is for IDs internal to PVFS.  For reference, id_gen_safe_register  
takes the pointer and adds it to a hashtable, so that we can check if  
its already been destroyed when we do id_gen_safe_lookup.  This is  
really only useful for the ids we pass back to the user through the  
system interfaces though, as we don't have any control there over  
whether they will pass in invalid ids.  For the ids internal to the  
code, we don't need the overhead of checking that all our pointers  
are valid, so id_gen_fast_register just casts the pointer value to a  
64bit value.

>
> What is the best way to catch changes like this so I can keep  
> bmi_mx up to date with CVS?

Honestly I thought I had changed the id_gen_safe calls in bmi_mx to  
id_gen_fast calls, so that's my bad.  To catch things like this, we  
should add nightly tests with the mx method enabled.  We've got some  
nodes here with mx, but we don't always have access to them.  If  
you've got a few nodes for testing, we can help you setup the tests  
and notification stuff to report to our tinderbox.  In an ideal  
world, we would have regular performance tests of PVFS and the mx  
code running as well, but I suppose that's a pipe dream.

-sam

>
> Thanks,
>
> Scott
>
> On Sep 7, 2007, at 4:04 PM, Sam Lang wrote:
>
>>
>> Hi Scott,
>>
>> You don't need to use id_gen_safe for your ids.  If you switch to  
>> using id_gen_fast_register, it should fix the abort you're  
>> seeing.  The abort is caused by the gen_safe code not being  
>> initialized by default on the server now, unless components  
>> actually need to use it.
>>
>> -sam
>>
>> On Sep 7, 2007, at 1:44 PM, Scott Atchley wrote:
>>
>>> Hi all,
>>>
>>> I am trying a fresh checkout of PVFS2 from this morning. I have a  
>>> single server and a single client.
>>>
>>> As soon as the client connects, the server aborts. Using gdb, the  
>>> server calls BMI_mx_post_send_list(). This function calls my  
>>> common send function, bmx_post_send_common, which calls  
>>> id_gen_safe_register().
>>>
>>> In that function, there is an assert which fails:
>>>
>>> (gdb)
>>> 61      int id_gen_safe_register(
>>> 62          PVFS_id_gen_t *new_id,
>>> 63          void *item)
>>> 64      {
>>> 65          id_gen_safe_t *id_elem = NULL;
>>> 66
>>> 67          assert(s_id_gen_safe_table != NULL);
>>> 68
>>> (gdb) p s_id_gen_safe_table
>>> $8 = (struct qhash_table *) 0x0
>>>
>>> Where is this table initialized? Is this something I need to  
>>> worry about or is cvs broken?
>>>
>>> Thanks,
>>>
>>> Scott
>>> _______________________________________________
>>> Pvfs2-developers mailing list
>>> Pvfs2-developers at beowulf-underground.org
>>> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>>>
>>
>