Michael L Torrie wrote:
On Wed, 2006-04-05 at 15:30 -0700, Rick Jones wrote:
which seems to be an issue with the callback function field of the
GOptionEntry. Do folks think it is something really worth worrying
about or should I just blythly ignore it and move-on?
While it appears that this is harmless, I'd recommend that you
explicitly cast your functions to (void*). You'd actually have to do
this with pointers to integers as well.
The reason this is required is that GOptionEntry only wants (void *)
which it casts to either to the type you specified, whether it be an
integer or a function. So it is up to you to explicitly cast, or let
the compiler do it for you. Explicit casting is safer (prevents
mistakes).
OK, I'll do that.... time passes...
yep, the compiler (invoked as xlc_r now since this is threaded) has
stopped complaining. Alas, I still segfault at the end of my test. It
looks like my g_module_open()ed library may be dying right at a call to
a routine that is actually in the program itself. Having just learned
that doing that is not possible in a DLL under Windows I'm left
wondering if there are issues with that under AIX
rick jones
# ./netperf
Segmentation fault(coredump)
# dbx ./netperf core
Type 'help' for help.
[using memory image in core]
reading symbolic information ...
Segmentation fault in glink.fflush at 0xd1fda988 ($t1)
0xd1fda988 (fflush+0x30) 800c0000 lwz r0,0x0(r12)
(dbx) dump
glink.fflush() at 0xd1fda988
(dbx) registers
$r0:0xd1fd31dc $stkp:0x2ff22990 $toc:0xf0cf5350 $r3:0x2008b488
$r4:0x2001adbc $r5:0x2008b3e8 $r6:0x2ff229e0 $r7:0x00000000
$r8:0x100b1091 $r9:0x100b1091 $r10:0x2002e1d8 $r11:0x00000000
$r12:0x0147e600 $r13:0xdeadbeef $r14:0x00000001 $r15:0x2ff22c8c
$r16:0x2ff22c94 $r17:0x00000000 $r18:0xdeadbeef $r19:0xdeadbeef
$r20:0xdeadbeef $r21:0xdeadbeef $r22:0xdeadbeef $r23:0xdeadbeef
$r24:0xdeadbeef $r25:0xdeadbeef $r26:0xdeadbeef $r27:0xdeadbeef
$r28:0xdeadbeef $r29:0xdeadbeef $r30:0x20004b38 $r31:0xd1fdb360
$iar:0xd1fda988 $msr:0x0000d0b2 $cr:0x22282388 $link:0xd1fd40f4
$ctr:0xd0132a80 $xer:0x20000008 $mq:0xdeadbeef
Condition status = 0:e 1:e 2:e 3:l 4:e 5:eo 6:l 7:l
[unset $noflregs to view floating point registers]
[unset $novregs to view vector registers]
in glink.fflush at 0xd1fda988 ($t1)
0xd1fda988 (fflush+0x30) 800c0000 lwz r0,0x0(r12)
not knowing anything about Power assembly, but guessing, is that a wide
load into r0 of something zero bytes from the address in r12?
(dbx) up
update_results_and_confidence(test_set = 0x2001ad98), line 2828 in
"nettest_bsd.c"
(dbx) list
2828 confidence = get_confidence(rd->run_time,
2829 &(test_set->confidence),
2830 &(rd->ave_time),
2831 &(temp));
2832 rd->result_confidence = get_confidence(rd->results,
2833 &(test_set->confidence),
2834 &(rd->result_measured_mean),
2835 &(rd->result_interval));
2836 if (test_set->debug) {
2837 fprintf(test_set->where,
(dbx) dump
update_results_and_confidence(test_set = 0x2001ad98), line 2828 in
"nettest_bsd.c"
rd = 0x2008b3b8
temp = 4.1126813125747635e-314
__func__ = "update_results_and_confidence"
confidence = 1.0
what is particularly perplexing is that while there is a fflush() call
above line 2828, it is inside an if{} that I know is not being executed,
which means that fflush was not executed so I'm rather confused about
dbx showing fflush at the end of the call chain.
_______________________________________________
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
