t/dynpmc/foo fails

[kjs]

This test keeps failing on my win32 system:

t/dynpmc/foo...........................NOK 3/9#   Failed test 'loadlib with absolute pathname, no ext'
#   at t/dynpmc/foo.t line 57.
# Exited with error code: 1
# Received:
# Class 'Foo' not found
# current instr.: 'main' pc 16 (C:\Documents and Settings\klaas-jan.stol\My Documents\parrot4\t\dynpmc\foo_3.pir:15)
#
# Expected:
# 42
#
# Looks like you failed 1 test of 9.
t/dynpmc/foo...........................dubious
        Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 3
        Failed 1/9 tests, 88.89% okay (less 1 skipped test: 7 okay, 77.78%)

[jkeenan]

This appears to be a reoccurrence of a problem we thought we had licked last week. See  RT 60940.

[rurban]

my backtrace for every loadlib on dynpmc on mingw32 is:

src\string\api.c:767: failed assertion 'encoding'


(gdb) b src\string\api.c:767
Breakpoint 1, Parrot_str_new_init (interp=0x3d25b8, buffer=0x74a702 "fixed_8", len=7, encoding=0x3d4d60, cha
    flags=12288) at src/string/api.c:767
767         ASSERT_ARGS(Parrot_str_new_init)
(gdb) bt
#0  Parrot_str_new_init (interp=0x3d25b8, buffer=0x74a702 "fixed_8", len=7, encoding=0x3d4d60, charset=0x0,
    flags=12288) at src/string/api.c:767
#1  0x00404c0a in Parrot_str_new_constant (interp=0x3d25b8, buffer=0x74a702 "fixed_8") at src/string/api.c:6
#2  0x00476900 in register_encoding (interp=0x3d25b8, encodingname=0x74a702 "fixed_8", encoding=0x3d4d60)
    at src/string/encoding.c:341
#3  0x00476a0b in Parrot_register_encoding (interp=0x3d25b8, encodingname=0x74a702 "fixed_8", encoding=0x3d4
    at src/string/encoding.c:374
#4  0x004e19f4 in Parrot_encoding_fixed_8_init (interp=0x3d25b8) at src/string/encoding/fixed_8.c:647
#5  0x0047617b in Parrot_charsets_encodings_init (interp=0x3d25b8) at src/string/charset.c:455
#6  0x00405225 in Parrot_str_init (interp=0x3d25b8) at src/string/api.c:304
#7  0x00401759 in make_interpreter (parent=0x0, flags=0) at src/inter_create.c:179
#8  0x00408db9 in Parrot_new (parent=0x0) at src/embed.c:103
#9  0x0040132b in main (argc=2, argv=0x3d2520) at src/main.c:52

(gdb) p *encoding
$1 = {name = 0x74a702 "fixed_8", max_bytes_per_codepoint = 1, to_encoding = 0x4e0f40 <to_encoding>,
  get_codepoint = 0x4e1030 <get_codepoint>, set_codepoint = 0x4e1150 <set_codepoint>, get_byte = 0x4e0fa0 <get_byte>,
  set_byte = 0x4e10b0 <set_byte>, get_codepoints = 0x4e1290 <get_codepoints>,
  get_codepoints_inplace = 0x4e13f0 <get_codepoints_inplace>, get_bytes = 0x4e11d0 <get_bytes>,
  get_bytes_inplace = 0x4e1320 <get_bytes_inplace>, set_codepoints = 0x4e1550 <set_codepoints>,
  set_bytes = 0x4e14a0 <set_bytes>, become_encoding = 0x4e1600 <become_encoding>, codepoints = 0x4e16a0 <codepoints>,
  bytes = 0x4e1660 <bytes>, iter_init = 0x4e18a0 <iter_init>}

(gdb) b src\string\api.c:767 if !encoding

(gdb) c
Continuing.

Breakpoint 3, Parrot_str_new_init (interp=0x3d25b8, buffer=0x6778879a "DynLexPad", len=9, encoding=0x0, charset=0x0,
    flags=12288) at src/string/api.c:767
767         ASSERT_ARGS(Parrot_str_new_init)

(gdb) bt
#0  Parrot_str_new_init (interp=0x3d25b8, buffer=0x6778879a "DynLexPad", len=9, encoding=0x0, charset=0x0,
    flags=12288) at src/string/api.c:767
#1  0x686820ba in Parrot_str_new_constant (interp=0x3d25b8, buffer=0x6778879a "DynLexPad") at src/string/api.c:687
#2  0x677843e3 in Parrot_lib_dynlexpad_load (interp=0x3d25b8) at dynlexpad.c:1453
#3  0x004cd8a8 in Parrot_init_lib (interp=0x3d25b8, load_func=0x677843b0 <Parrot_lib_dynlexpad_load>, init_func=0)
    at src/dynext.c:349
#4  0x004cda5a in run_init_lib (interp=0x3d25b8, handle=0x67780000, lib_name=0xe82490, wo_ext=0xe82490)
    at src/dynext.c:414
#5  0x004ce13c in Parrot_load_lib (interp=0x3d25b8, lib=0xdf4f90, initializer_unused=0x0) at src/dynext.c:621
#6  0x0042ccab in Parrot_loadlib_p_sc (cur_opcode=0xea0c00, interp=0x3d25b8) at src/ops/core.ops:1330
#7  0x0060019f in runops_slow_core (interp=0x3d25b8, pc=0xea0c00) at src/runops_cores.c:228
#8  0x004b61cf in runops_int (interp=0x3d25b8, offset=0) at src/interpreter.c:978
#9  0x00410fb6 in runops (interp=0x3d25b8, offs=0) at src/inter_run.c:108
#10 0x00411207 in runops_args (interp=0x3d25b8, sub=0xe72128, obj=0xe2e198, meth_unused=0x0, sig=0x725d17 "vP",
    ap=0x22febc "\020!þ") at src/inter_run.c:248
#11 0x00411f18 in Parrot_runops_fromc_args (interp=0x3d25b8, sub=0xe72128, sig=0x725d17 "vP") at src/inter_run.c:315
#12 0x00409e89 in Parrot_runcode (interp=0x3d25b8, argc=1, argv=0x3d2524) at src/embed.c:984
#13 0x00403135 in imcc_run_pbc (interp=0x3d25b8, obj_file=0, output_file=0x0, argc=1, argv=0x3d2524)
    at compilers/imcc/main.c:824
#14 0x00403ca3 in imcc_run (interp=0x3d25b8, sourcefile=0x3d24ad "t\\\\dynpmc\\\\dynlexpad_1.pir", argc=1,
    argv=0x3d2524) at compilers/imcc/main.c:1111
#15 0x004013a0 in main (argc=1, argv=0x3d2524) at src/main.c:61

Infinoid knows why: Does it happen at the very beginning of parrot execution, before any encodings have been registered? (the default encoding pointer will be NULL in that case)  http://irclog.perlgeek.de/parrot/2009-02-06#i_889824

[rurban]

I tried to workaround this by adding this, but it failed. There are more missing structures on a dynpmc dll init.

--- src/string/api.c    (revision 36403)
+++ src/string/api.c    (working copy)
@@ -684,6 +684,13 @@
     if (s)
         return s;

+#ifdef WIN32
+    if (!PARROT_DEFAULT_CHARSET) { /* hack for TT #276, dynpmc init only on Win32 */
+        Parrot_charsets_encodings_init(interp);
+        printf("Parrot_str_new_constant re-init: charset=0x%x, encoding=0x%x\n",
+               PARROT_DEFAULT_CHARSET, PARROT_DEFAULT_ENCODING);
+    }
+#endif
     s = Parrot_str_new_init(interp, buffer, strlen(buffer),
                        PARROT_DEFAULT_ENCODING, PARROT_DEFAULT_CHARSET,
                        PObj_external_FLAG|PObj_constant_FLAG);

=>

parrot-mingw>parrot t\dynpmc\dynlexpad_1.pir
Parrot_str_new_constant re-init: charset=0xe8fea0, encoding=0xe8f688
Null PMC access in get_integer()
current instr.: 'main' pc 0 (t\dynpmc\dynlexpad_1.pir:3)

(gdb) b Parrot_Null_get_integer
Breakpoint 3 at 0x5f4e86: file src/pmc/null.c, line 463. (2 locations)
(gdb) run
Starting program: N:\usr\src\perl\parrot\parrot-mingw/parrot.exe t\\dynpmc\\dynlexpad_1.pir
[New thread 4640.0x1454]
Parrot_str_new_constant re-init: charset=0xea0008, encoding=0xe9fdb8

Breakpoint 3, Parrot_Null_get_integer (interp=0x3d25b8, pmc=0xe2e198) at src/pmc/null.c:463
463     {
(gdb) bt
#0  Parrot_Null_get_integer (interp=0x3d25b8, pmc=0xe2e198) at src/pmc/null.c:463
#1  0x68737fe1 in pmc_type (interp=0x3d25b8, name=0xdf4e78) at src/pmc.c:597
#2  0x68738069 in pmc_register (interp=0x3d25b8, name=0xdf4e78) at src/pmc.c:551
#3  0x677843fa in Parrot_lib_dynlexpad_load (interp=0x3d25b8) at dynlexpad.c:1454
#4  0x004cd908 in Parrot_init_lib (interp=0x3d25b8, load_func=0x677843b0 <Parrot_lib_dynlexpad_load>, init_func=0)
    at src/dynext.c:349
#5  0x004cdaba in run_init_lib (interp=0x3d25b8, handle=0x67780000, lib_name=0xe82490, wo_ext=0xe82490)
    at src/dynext.c:414
#6  0x004ce19c in Parrot_load_lib (interp=0x3d25b8, lib=0xdf4f90, initializer_unused=0x0) at src/dynext.c:621
#7  0x0042cd0b in Parrot_loadlib_p_sc (cur_opcode=0xea0c00, interp=0x3d25b8) at src/ops/core.ops:1330
#8  0x006001ff in runops_slow_core (interp=0x3d25b8, pc=0xea0c00) at src/runops_cores.c:228
#9  0x004b622f in runops_int (interp=0x3d25b8, offset=0) at src/interpreter.c:978
#10 0x00411016 in runops (interp=0x3d25b8, offs=0) at src/inter_run.c:108
#11 0x00411267 in runops_args (interp=0x3d25b8, sub=0xe72128, obj=0xe2e198, meth_unused=0x0, sig=0x725d77 "vP",
    ap=0x22febc "\020!þ") at src/inter_run.c:248
#12 0x00411f78 in Parrot_runops_fromc_args (interp=0x3d25b8, sub=0xe72128, sig=0x725d77 "vP") at src/inter_run.c:315
#13 0x00409ee9 in Parrot_runcode (interp=0x3d25b8, argc=1, argv=0x3d2524) at src/embed.c:984
#14 0x00403135 in imcc_run_pbc (interp=0x3d25b8, obj_file=0, output_file=0x0, argc=1, argv=0x3d2524)
    at compilers/imcc/main.c:824
#15 0x00403ca3 in imcc_run (interp=0x3d25b8, sourcefile=0x3d24ad "t\\\\dynpmc\\\\dynlexpad_1.pir", argc=1,
    argv=0x3d2524) at compilers/imcc/main.c:1111
#16 0x004013a0 in main (argc=1, argv=0x3d2524) at src/main.c:61
(gdb)

[rurban]

The missing encoding in the dll is fixed by either re-registering it on WIN32 only (my patch above) or by  http://nopaste.snit.ch/15529 +  http://nopaste.snit.ch/15530 (moving the encoding and charset from global to interp).

But the remaining problem is Parrot_Null_get_integer(), and it is caused by a failing PMC_IS_NULL pointer comparison.

(gdb) up
#1  0x687440c7 in pmc_type (interp=0x3d25e0, name=0xe04098) at src/pmc.c:596
596             if (!PMC_IS_NULL(interp, item))
(gdb) p item
$5 = (PMC * const) 0xdbe458
(gdb) p PMCNULL
$6 = (PMC *) 0xdbe458

On mingw and probably MSVC this comparison is false, elsewhere true.

I've also tried the function PMC_is_null, ditto. The disassembly is weird, but I suppose the problem is caused by consting the Parrot_Null vtable pointers, where the compiler marks const pointers to be likely in a different segment (though they are not).

I'm now trying to const PMCNULL, as it seems to be the right thing.

[NotFound]

if (!PMC_IS_NULL(interp, item))

Be careful with this. The macro PMC_IS_NULL takes just one argument, the function PMC_is_null takes two.

[rurban]

The failing !PMC_is_null(interp, item) check was caused by my stupidness. (stopped generating libparrot.a static, but the linker still picked up the old lib.)

The real fix will be to disable static libparrot.a if not requested explicitly, because e.g. dynpmc and dynoplibs link with -shared and will link to the shared libparrot and then we'll have a conflict. => new ticket

The original problem was fixed by moving the global charset and encoding to interp by NotFound. This will have to go through one deprecation cycle though. => NotFound (macro for the old global names and adding interp where appropriate)

[allison]

Moving the charsets to the interpreter structure is the wrong fix. Rejected. A better fix is to make strings gracefully handle a null charset/encoding.

Fine with making dynamic the default on Windows, as long as static libparrot.a still works.

[rurban]

Should be fixed now, but a better solution will be TT#312, disable static on win32 if shared.

[rurban]

See TT#313 for a real fix, when being installed.

mingw works fine now, because the static lib is in blib/lib and not disturbing us. msvc still fails because the static lib is in build_dir and no importlib is built.

> perl t\harness t\dynpmc\*.t

t\dynpmc\dynlexpad.t    6  1536     7    6  85.71%  1-6
t\dynpmc\foo.t          8  2048     9    8  88.89%  1-5 7-9
t\dynpmc\pair.t                    ??   ??       %  ??
t\dynpmc\rotest.t       8  2048     8    8 100.00%  1-8
t\dynpmc\subproxy.t     2   512     2    2 100.00%  1-2

See the attached patch tt276-msvc-linking.patch

[rurban]

target against #276 + #313

[coke]

(the platform is already marked as win32. no need to put it in the summary too.)

[whiteknight]

Is this ticket still an issue? It seems to me like we get plenty of passing Win32 tests reported to smolder. My local testing does not show a problem. I'm tempted to mark this as WORKSFORME if nobody objects.

[cotto]

I see a couple failing tests on win32 (mingw and msvc), but this isn't one of them. I'm marking this as fixed.