Created attachment 451 [details] client-server example that reproduces the bug on marshaling huge strings I've experiencing a MARSHAL exception when I use a huge string as parameter (or even as return value). In my test, I used a 10000 length string containing the char '1'. Exception on server-side: org.omg.CORBA.MARSHAL: unexpected string terminator value 31 at buffer index 108 at org.jacorb.orb.CDRInputStream.read_string(CDRInputStream.java:1253) at test.bigsize.TestPOA._invoke(TestPOA.java:46) at org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:350) at org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:672) at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:830) IDL: module test { module bigsize { interface Test { void input(in string s1); }; }; }; Part of message request (I used jacorb.debug.dump_outgoing_messages=on): 47 49 4F 50 01 02 00 00 00 00 27 71 00 00 00 00 GIOP .... ..'q .... 03 00 00 00 00 00 00 00 00 00 00 22 34 32 32 30 .... .... ..." 4220 31 35 34 31 37 33 2F 00 01 10 43 00 03 04 10 01 1541 73/. ..C. .... 42 04 46 10 06 30 46 38 14 14 1B 48 4C 1B 00 00 B.F. .0F8 ...H L... 00 00 00 06 69 6E 70 75 74 00 00 00 00 00 00 01 .... inpu t... .... 00 00 00 01 00 00 00 0C 00 00 00 00 05 01 00 01 .... .... .... .... 00 01 01 09 00 00 00 22 00 00 00 01 31 31 31 31 .... ..." .... 1111 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 1111 1111 1111 1111 I can see the error on "00 00 00 01", it should be the size of string and not 0x1. When I tried JacORB 3.4 (and lower versions) it works fine and I got "00 00 27 11" as expected instead of "00 00 00 01". In order to execute my test (attached): mvn compile mvn dependency:copy-dependencies ./runserver ./runclient Thank you in advance, Amadeu A. Barbosa Jr
Thanks for the excellent test case - reproduced. Initial investigation - I think its an interaction with bug 941 when codesets are enabled.
Created attachment 452 [details] client-server example that reproduces the bug on marshaling small strings inside huge requests It seems that is not about string itself but (maybe) the CDR processing of big size requests. I modify my example to use big size byte sequences inside a struct Data like: typedef sequence<octet> octetseq; struct Data { octetseq bytes; string name; } And I filled it with 10000 bytes in Data.bytes and the simple string "first" in Data.name and I got the problem reproduced also. The instructions to compile/execute is the same than previously attached file.
I believe the problem is within deferredArrayQueue. A workaround would be to set it to 0 (default is 8). An unanswered question is, with modern JVMs/OS, how much actual benefit it brings (the original code dates from 2002).
Fixed by SHA 4a70d6d1dcd90d8bf0290f995beeb1d09000cdb6