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
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
