Issue 115716 - basic: Using strings with external functions (e.g. Windows API) leads to memory trash being received
Summary: basic: Using strings with external functions (e.g. Windows API) leads to memo...
Alias: None
Product: General
Classification: Code
Component: scripting (show other issues)
Version: OOO330m15
Hardware: PC Windows XP
: P3 Trivial (vote)
Target Milestone: 3.4.0
QA Contact: issues@framework
Keywords: oooqa, regression
Depends on:
Reported: 2010-11-22 10:28 UTC by hitec_tsc
Modified: 2011-01-24 09:45 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Test Macros (1.30 KB, text/plain)
2010-11-22 10:30 UTC, hitec_tsc
no flags Details
Screenshot of windows registry (14.67 KB, text/plain)
2010-11-22 10:31 UTC, hitec_tsc
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description hitec_tsc 2010-11-22 10:28:41 UTC
We have used this kind of macros to save some settings for our company's OOo
macros (see attachment) for about two years now and never had problems with it
until I recently tested the macros with OOo 3.3 RC6.
With that version, every now and then, cannot tell exactly when and why, basic
came up with the error "Aktion nicht unterstützt. Ungültiger Prozeduraufruf"
(translates to: 'Action not supported. Bad procedure-call' or something similar).
But sometimes there was no error and the macros got executed. I was kind of
confused until I checked the Windows registry and saw the keys which were
created in there by the macros (see attachment 2 [details]). 
I am pretty clueless why this happens, but this is a major problem for us, since
we are using the Windows API (especially the registry calls) alot and it would
cost me alot of time to rewrite all macros to use ini-files or something.

Executing the macro in attachment 1 [details] should be able to reproduce this error.
Comment 1 hitec_tsc 2010-11-22 10:30:28 UTC
Created attachment 75090 [details]
Test Macros
Comment 2 hitec_tsc 2010-11-22 10:31:02 UTC
Created attachment 75091 [details]
Screenshot of windows registry
Comment 3 Marcus 2010-11-23 10:20:14 UTC
for user help please see the forums:
Comment 4 Marcus 2010-11-23 10:20:53 UTC
Comment 5 hitec_tsc 2010-11-23 12:22:26 UTC
How is this closed? I just tried it in RC6, because I thought it was fixed in
there or just an issue with RC5, but it is still the same. These calls worked
just fine till the last RC. A bit more of an explanation would be really
appreciated, instead of refering to the most general forum link there is.
Sorry, but this is really frustrating, because it just kills every macro our
company is using and I cannot see the problem myself.
Comment 6 Mechtilde 2010-11-23 15:44:10 UTC
@ jsc

are there some changes in the API?
Comment 7 jsc 2010-11-23 19:11:06 UTC
jsc -> ab: do you have an idea? I think we should take a look on it
Comment 8 kay.ramme 2010-11-25 08:10:57 UTC
->mla: what was the reason to close this?
Comment 9 hitec_tsc 2010-11-25 16:28:38 UTC
This issue is reproducable for me in a freshly installed Windows 7 with OOo 3.3
RC6 by the way.
Comment 10 ab 2010-11-26 08:14:46 UTC
ab->sb: Basic-DLL-Interface related, please have a look
Comment 11 Stephan Bergmann 2010-11-26 10:33:46 UTC
Hamburg-internal issue #162141# "Runtime does not handle strings in the right
way" changed the marshaling of Basic data used in "external DLL" calls (changes
to basic/source/runtime/dllmgr.cxx, lumped together with many other things in
<>).  The corresponding
tests unfortunately only checked that strings passed back from such an
"external" call were correct (the string used in GetLogicalDriveStrings from
kernel32.dll to return a list of null-separated drive strings).

What apparently broke, however, is (1) to pass strings into such "external"
calls ("Software\OOo_TEST_KEY" in lpSubKey of RegCreateKeyA, "OOo_TEST_DATA"
lpValueName of RegSetValueExA), and (2) to pass strings into such "external"
calls via "Any" ("THIS IS A TEST" in lpData of RegSetValueExA).

For (1), the problem is that the terminating null byte is missing from the
marshaled string data.  The following patch would fix that:

--- a/basic/source/runtime/dllmgr.cxx   Tue Nov 23 16:56:16 2010 +0100
+++ b/basic/source/runtime/dllmgr.cxx   Fri Nov 26 11:30:51 2010 +0100
@@ -207,6 +207,7 @@
     std::vector< char > * blob = data.newBlob();
     blob->insert(blob->begin(), str.getStr(), str.getStr() + str.getLength());
+    blob->push_back(0);
     *buffer = address(*blob);
     data.unmarshalStrings.push_back(StringData(variable, *buffer, special));
     return ERRCODE_NONE;
Comment 12 Stephan Bergmann 2010-11-26 12:38:18 UTC
The second problem (pass string via "Any") might be a problem of the given test
code or a problem of the Basic runtime implementation.  I filed new issue 115795
to address this.
Comment 13 Stephan Bergmann 2010-12-07 16:24:52 UTC
fixed as <>
Comment 14 Stephan Bergmann 2011-01-05 09:26:25 UTC
[CWS sb137 has been abandoned in favor of CWS sb135, fix for this issue has thus
been pulled into cws/sb135]
Comment 15 Stephan Bergmann 2011-01-06 16:15:02 UTC
@tbo: please verify
Comment 16 2011-01-13 08:17:15 UTC
Verified in CWS sb135 with attached macro;
The name of the entry is now ok in registry written.
Comment 17 cno 2011-01-20 10:02:24 UTC
could integration in 3.3.1 pls be considerd? Thanks!
Comment 18 2011-01-24 09:45:45 UTC
integrated into master DEV300m98 - closing