Confirmed in

Versió: 6.0.0.0.alpha0+
ID de la construcció: 0342c5e8086c8200ecadbe9d52dd4ef6a093effb
CPU threads: 4; OS: Linux 4.10; UI render: per defecte; VCL: gtk3; 
Configuració local: ca-ES (ca_ES.UTF-8); Calc: group

Regression introduced by:

author	Noel Grandin <noel.grandin@collabora.co.uk>	2017-02-09 06:52:13 (GMT)
committer	Noel Grandin <noel.grandin@collabora.co.uk>	2017-06-21 06:42:30 (GMT)
commit 528632660b72b105345945c13c5b68060d94a91b (patch)
tree 860508d482959abeb9175f0ce6b9e65954269f95
parent aee66aa85e75f67135e5c6079a281e18402d261a (diff)
convert ErrCode to strong typedef
would have preferred to re-use o3tl::strong_int, of which this
is a modified copy, but there are lots of convenience accessors
which are nice to define on the class.

bisected with bibisect-linux64-6.0

Adding Cc: to Noel Grandin

Scratch that, that piece of code must've behaved the same before as well.

Created attachment 135479 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated yesterday, noticing this trace:
warn:legacy.osl:6627:1:vcl/source/window/errinf.cxx:177: Error not handled
I retrieved the bt from there if it can help.

In lcl_showGeneralSfxErrorOnce (see https://opengrok.libreoffice.org/xref/core/sfx2/source/doc/docmacromode.cxx#86), I noticed this:
(gdb) p nSfxErrorCode
$12 = {m_value = 2147500084}
(gdb) p aErrorCodeRequest.ErrCode
$13 = -2147467212

In https://opengrok.libreoffice.org/xref/core/offapi/com/sun/star/task/ErrorCodeRequest.idl, ErrCode is defined as a long.

Since 2147500084 > 2 power 31, the number is converted in negative.

(In reply to Julien Nabet from comment #6)
> Since 2147500084 > 2 power 31, the number is converted in negative.

Yeah, thats fine, that is the way it has always been, we convert backwards and forwards but the bitpattern stays the same.

Perhaps you could convert that OSL_FAIL in errinf.cxx to

  SAL_WARN( "vcl", "Error not handled " << pInfo->GetErrorCode());

?
and see what error is being ignored?

(In reply to Noel Grandin from comment #7)
> (In reply to Julien Nabet from comment #6)
> > Since 2147500084 > 2 power 31, the number is converted in negative.
> 
> Yeah, thats fine, that is the way it has always been, we convert backwards
> and forwards but the bitpattern stays the same.
Ok, I saw afterwards that negative values were dealt.

> Perhaps you could convert that OSL_FAIL in errinf.cxx to
> 
>   SAL_WARN( "vcl", "Error not handled " << pInfo->GetErrorCode());
> 
> ?
> and see what error is being ignored?
Here's the trace:
warn:vcl:13639:1:vcl/source/window/errinf.cxx:177: Error not handled 2147500084
this info + bt (frame 6 sfx2/source/doc/docmacromode.cxx:94), it seems to be ERRCODE_SFX_DOCUMENT_MACRO_DISABLED.

I submitted a patch to review here:
https://gerrit.libreoffice.org/#/c/41089/

I have spotted one issue with my commit, fix here:
   https://gerrit.libreoffice.org/#/c/41096/
anybody care to test?

(In reply to Noel Grandin from comment #9)
> I have spotted one issue with my commit, fix here:
>    https://gerrit.libreoffice.org/#/c/41096/
> anybody care to test?

Since this file is included in a lot of files, it's quite equivalent to build from scratch.
I propose you to push the patch if Jenkins doesn't complain about it. Indeed, it'll fix a bug fixed even it doesn't fix this bugtracker.

Once pushed, I'll update my local repo and launch a make clean && make

Seeing https://opengrok.libreoffice.org/search?project=core&q=MakeWarning&defs=&refs=&path=&hist=&type=, the patch won't help.
But seeing the git history of these 2 files, the fix is correct, that's why I put +2 for code review.

On pc Debian x86-64 with master sources updated today, I still reproduce this.
(and still see this on console:
warn:vcl:25837:1:vcl/source/window/errinf.cxx:177: Error not handled 2147500084)

The problem is with the construction of ERRCODE_SFX_DOCUMENT_MACRO_DISABLED (when it's actually substituted in RID_ERRHDL). Previously this had a nice value, something like 16436. Now it has that huge value, 2147500084, so when it looks for 16436, nothing is returned.

I couldn't identify why exactly the initialized value is different, possibly due to the change in type or something?

Very weird.

ErrorResource::getString in uui/ is calling getRest on the passed in errorCode before comparing to the value in the array.

The other things that get passed to ErrorResource::getString, their definitions look like:

	{ NC_("RID_UUI_ERRHDL", "The operation executed on $(ARG1) was aborted."),
          ErrCode(sal_uInt32(ERRCODE_UUI_IO_ABORT) & ERRCODE_RES_MASK) },

but RID_ERRHDL in svtools/inc/errtxt.hrc does not, it looks like:

        { NC_("RID_ERRHDL", "An attempt was made to execute a macro.\nFor security reasons, macro support is disabled."),
          ErrCode(ERRCODE_SFX_MACROS_SUPPORT_DISABLED) },


Similarly SfxErrorHandler::GetErrorString in sfx2/source/appl/appinit.cxx is casting to sal_uInt16 which has much the same effect as calling getRest() or anding with ERRCODE_RES_MASK.

How this used to work I don't know, I suspect that somehow the value in the old .hrc file was being truncated to 16 bits.

Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=26b97ba18e72f7c25c836177d895d429162a0120

tdf#111696 No macro security dialog with High setting

It will be available in 6.0.0.

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

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

With master sources udpated today, I don't reproduce this.

Thank you Noel!