Custom Query (33 matches)


Show under each result:

Results (7 - 9 of 33)

1 2 3 4 5 6 7 8 9 10 11
Ticket Owner Reporter Resolution Summary
#29 jsoumagne carns fixed HG_Handler_process() hang with na_bmi

This isn't 100% reproducable, but I seem to be hitting a case where HG_Handler_process() doesn't return, even though I'm specifying a timeout of 1.

The use cases is that I have a dedicated thread calling HG_Handler_process() in a loop, and I need to to break out of that call periodically to check if the daemon (and therefore this thread) is shutting down.

The stack trace looks like this when it is hung:

#0  na_bmi_progress_unexpected ([email protected]=0x1249710, 
    [email protected]=0x124b330, 
    [email protected]=0x2b7cbf247d57 "", timeout=0)
    at /home/pcarns/working/mercury/src/na/na_bmi.c:1665
#1  0x0000000000480707 in na_bmi_progress (na_class=0x1249710, 
    context=0x124b330, timeout=<optimized out>)
    at /home/pcarns/working/mercury/src/na/na_bmi.c:1634
#2  0x000000000047f024 in NA_Progress (na_class=0x1249710, context=0x124b330, 
    [email protected]=1) at /home/pcarns/working/mercury/src/na/na.c:859
#3  0x000000000047bfd0 in HG_Handler_process (timeout=1, 
    status=0x1 <Address 0x1 out of bounds>)
    at /home/pcarns/working/mercury/src/mercury_handler.c:882
#4  0x00000000004550a0 in svr_thread_fn (foo=0x0)
    at ../src/remote/
#5  0x00002b7cb95c5f6e in start_thread (arg=0x2b7cbf248700)
    at pthread_create.c:311
#6  0x00002b7cba1549cd in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

I have confirmed that na_bmi_progress_unexpected() is being called repeatedly, so BMI itself is not hanging.

I can't see the value of the timeout argument at the na_bmi_progress() level (need to recompile with different flags), but I can see the value of the double "remaining" variable within na_bmi_progress(), however, and its present value in my example is 4292707.9868252408. That's way too high since it is supposed to be in units of seconds. This is probably the reason why the function doesn't return.

I'll try to debug further later and see if I can observe why that variable value is getting so high in the first place, but I wanted to go ahead and post the symptoms here in trac.

#28 somebody jsoumagne fixed Add convenience routines to bulk data interface

when using mercury locally (ie without shipping anything), we need to be able to get bulk data without doing any memory copy and access it through pointers. We should add convenience routines that allow users to directly get a pointer when doing a bulk_read (HG_Bulk_read_ptr ?) / refactor API for this case.

#27 jsoumagne jsoumagne fixed Add callback version of HG_Bulk API

Switch mercury_bulk.h to callback model.

1 2 3 4 5 6 7 8 9 10 11
Note: See TracQuery for help on using queries.