On May 6, 2004, at 6:58 AM, Nicholas Clark wrote:
On Tue, May 04, 2004 at 02:55:25PM +0200, Leopold Toetsch wrote:Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
'libnci.so' is used for testing the native call interface. However I noticed
that the tests in t/pmc/nci.t were skipped, because 'libnci.so' wasn't built
by default. The attached patch adds that library to the target 'all'.
Thanks, applied. Let's see, which platforms break.
OS X.
With this patch I get make to pass, but I suspect that this patch will break
Win32, assuming that $(LIBNCI_SO) is libnci.dll on Win32, as there is a
second, explict libnci.dll target next in the Makefile
Yes, this should be the right way to go--we just need some configure work to add the "-def:libnci.def" that Win32 will need to build. (Who knows--other platforms might tolerate having that parameter there, and just ignore it.) But it should be as simple as adding a ${libnci_def} which only expands to anything on Win32.
Index: config/gen/makefiles/root.in =================================================================== RCS file: /cvs/public/parrot/config/gen/makefiles/root.in,v retrieving revision 1.205 diff -d -u -r1.205 root.in --- config/gen/makefiles/root.in 4 May 2004 12:55:21 -0000 1.205 +++ config/gen/makefiles/root.in 6 May 2004 13:51:12 -0000 @@ -1141,7 +1141,7 @@
$(SRC)/libnci$(O): $(SRC)/nci_test.c
-$(DYNEXT_DIR)/libnci.so: $(SRC)/nci_test$(O) +$(LIBNCI_SO): $(SRC)/nci_test$(O) $(LD) $(LD_SHARED) $(LDFLAGS) \ $(LD_OUT)$@ $(SRC)/nci_test$(O)
However, with this I now have a failing regression test. running in gdb:
Starting program: /Users/nick/Parrot/parrot02/parrot -b --gc-debug /Users/nick/Parrot/parrot02/t/pmc/nci_20.pasm
Looks like some tests have been added--it's nci_22.pasm failing for me now (but identical results, so it's probably the same test).
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x0002e354 in pobject_lives (interpreter=0x1000200, obj=0xd13a68) at src/dod.c:194
194 PObj_live_SET(obj);
(gdb) print *obj
$1 = {
obj = {
u = {
_b = {
_bufstart = 0x7c0802a6,
_buflen = 3217162232
},
_ptrs = {
_struct_val = 0x7c0802a6,
_pmc_val = 0xbfc1fff8
},
_int_val = 2080899750,
_num_val = 2.9248558425698019e+289,
_string_val = 0x7c0802a6
},
flags = 2415984648,
_pobj_version = 2485256112
}
}
which is now confusing me mightily, because I can change the value of flags
inside gdb with a set command. Yet attempting to restart the process will
fail with the EXC_BAD_ACCESS signal straight away.
Am I confusing what EXC_BAD_ACCESS means? Error is here:
It's probably crashing trying to get the arena or something; CrashReporter fished out this for me:
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00d30a78
which means it's probably trying to write to memory which is write-protected. Not sure, but it's just because the pobj has been trashed, because....
#2 0x0002f224 in Parrot_do_dod_run (interpreter=0x1000200, flags=1) at src/dod.c:1051
#3 0x000321c8 in string_compare (interpreter=0x1000200, s1=0x1001ba8, s2=0x1012a40) at src/string.c:1710
#4 0x001e4360 in build_call_func (interpreter=0x1000200, pmc_nci=0x100f6a0, signature=0x1001ba8) at src/nci.c:2925
This is the problem. We need to get rid of this code:
#3 0x00031d48 in string_compare (interpreter=0x1000200, s1=0x1001ba8, s2=0x1012a40) at src/string.c:1710
1710 Parrot_do_dod_run(interpreter, DOD_trace_stack_FLAG);
(gdb) l
1705 }
1706
1707 # if ! DISABLE_GC_DEBUG
1708 /* It's easy to forget that string comparison can trigger GC */
1709 if (GC_DEBUG(interpreter))
1710 Parrot_do_dod_run(interpreter, DOD_trace_stack_FLAG);
1711 # endif
Basically, when running with --gc-debug, we trigger a DOD run inside of string_compare, which is trashing the strings we've just made (and are in the middle of using) in build_call_func:
2925 if (!string_compare(interpreter, signature, 2926 string_from_cstring(interpreter, "cv", 0))) 2927 return F2DPTR(pcf_c_v);
(The result of string_from_cstring isn't really rooted anywhere.)
Since my strings patch, we no longer allocate memory inside of string_compare, so arguably this is a bogus time to be triggering DOD. But, if we think that subsequent changes will bring back the need to allocate memory inside of a comparison operation, then we need to redo build_nativecall.pl to generate build_call_func() differently, to root the temporary strings it's creating. Also, it's slow as molasses, since it's triggering 156 DOD runs for every NCI call (which causes t/pmc/nci_9.pasm to essentially never finish if run with --gc-debug), so we'd want to change that too.
But the easiest thing is to get rid of src/string.c:1707-1711 (see above), which should fix t/pmc/nci.t:9,22 on Mac OS X.
JEff
