Bug 136143

Summary:	Regression Err:448 in Optional arguments
Product:	LibreOffice	Reporter:	Jean-Pierre Ledure <jp>
Component:	BASIC	Assignee:	Andreas Heinisch <andreas.heinisch>
Status:	VERIFIED FIXED
Severity:	normal	CC:	andreas.heinisch, himajin100000, info, ingpaolo, jp, mikekaganski, serval2412
Priority:	high
Version:	7.0.0.3 release
Hardware:	All
OS:	All
See Also:	https://bugs.documentfoundation.org/show_bug.cgi?id=149959
Whiteboard:	target:7.1.0 target:7.0.2
Crash report or crash signature:		Regression By:
Bug Depends on:
Bug Blocks:	136063
Attachments:	Error448.odt with Basic code

Description Jean-Pierre Ledure 2020-08-26 11:06:59 UTC

Created attachment 164709 [details]
Error448.odt with Basic code

When running Main() in next Basic code, containing a cascade of calls with uninitialized optional arguments, the behaviour is different between LO 6.4.5 and LO 7.0.0

Sub Main
Dim a
	a = 1
	SubA(a)
End Sub

Sub SubA(a, Optional x, Optional y)
	SubB(a, x, y)
End Sub

Sub SubB(a, Optional x, Optional y)
	If IsMissing(x) Then x = 2
	MsgBox x
End Sub

In 6.4, the execution ends with the message box containing "2", as expected.

In 7.0 however, the execution aborts on the statement "x = 2" with the error message
"Inadmissible value or data type. Data type mismatch."

The reason, AFAIK, seems to be that variable x in SubB is of type
- Variant/Error in LO6.4
- Error in LO 7.0
the latter preventing a reset of x to another value.

To reproduce the issue:
----------------------
- open the attached Error448.odt file
- open the Basic IDE
- in the Basic module of the file "Module1", run Main()

Result in 7.0:
-------------
Error "Inadmissible value or data type. Data type mismatch."

Expected result:
---------------
No error message


PS: current bug is the root cause of https://bugs.documentfoundation.org/show_bug.cgi?id=136063

Comment 1 Andreas Heinisch 2020-08-26 16:54:31 UTC

Confirmed in:

Version: 7.1.0.0.alpha0+ (x64)
Build ID: 8b55854e51d085c17a1d6c85bbd626812c6b25b5
CPU threads: 6; OS: Windows 10.0 Build 17134; UI render: Skia/Vulkan; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: CL

Comment 2 Commit Notification 2020-08-27 13:49:41 UTC

Andreas Heinisch committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/781b6ac998370f2923c0783100da7086bfad622d

tdf#136143 - reset SbxFlagBits::Fixed SbiRuntime::StepPARAM

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Comment 3 Jean-Pierre Ledure 2020-08-27 14:09:36 UTC

Thank you, Andreas.

Please, could the patch be applied on 7.0 as well ?

Comment 4 Mike Kaganski 2020-08-27 14:19:59 UTC

(In reply to Jean-Pierre Ledure from comment #3)

Please don't change the automatically added tags, that have their meaning (in this case, it indicates that there's a patch that fixes that in 7.1.0).

When the change will be backported and merged to 7.0, it will get the appropriate mark there as well, automatically.

Comment 5 Commit Notification 2020-08-28 15:17:30 UTC

Andreas Heinisch committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/cfbc7fd2991874b164cc6398a4f8dc681eabe63f

tdf#136143 - reset SbxFlagBits::Fixed SbiRuntime::StepPARAM

It will be available in 7.0.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Comment 6 Jean-Pierre Ledure 2020-09-10 15:33:56 UTC

I confirm that the fix solved the issue in 7.1.

Changed the status to VERIFIED.

Thanks, Andreas !

Comment 7 Jean-Pierre Ledure 2020-09-10 15:37:04 UTC

(In reply to Mike Kaganski from comment #4)
> (In reply to Jean-Pierre Ledure from comment #3)
> 
> Please don't change the automatically added tags, that have their meaning
> (in this case, it indicates that there's a patch that fixes that in 7.1.0).
> 
> When the change will be backported and merged to 7.0, it will get the
> appropriate mark there as well, automatically.

Ooops. I didn't know that the field was managed automatically.
Sorry for the disturbance.

Comment 8 Jean-Pierre Ledure 2020-09-11 15:07:13 UTC

*** Bug 136063 has been marked as a duplicate of this bug. ***

Comment 9 Jean-Pierre Ledure 2020-10-01 09:58:00 UTC

*** Bug 137150 has been marked as a duplicate of this bug. ***