<Swing Dev> swing-dev Digest, Vol 130, Issue 13
Prasanta Sadhukhan
prasanta.sadhukhan at oracle.com
Mon Feb 12 08:03:35 UTC 2018
I did try with tests on C:/prasanta/8189938/JDK-8189938-master too which
is NTFS but it still fails with same issue.
Regards
Prasanta
On 2/12/2018 1:11 PM, Reinhard Pointner wrote:
> Using a different drive might be worth a try. Does D: happen to be a
> remote network drive or host folder mounted into the VM? I found some
> docs that indicate that NTFS filesystem is required for APPX packages.
>
> I have my tests on C:\Development which is also my Windows System
> Partition / Drive and formatted with NTFS.
>
> Regards,
> Reinhard
>
> On 12 Feb 2018 12:21, "Prasanta Sadhukhan"
> <prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com>>
> wrote:
>
> Hi Reinhard,
>
> This is the event log from powershell. I took a look into
> http://go.microsoft.com/fwlink/?LinkId=235160
> <http://go.microsoft.com/fwlink/?LinkId=235160> but could not get
> 0x80070005 error code there, but it seems to be a general access
> denied problem. Not sure what access rights I need to give.
> Get-AppxLog -ActivityID 02867602-9e78-0003-0675-8902789ed301
>
> Time ID Message
> ---- -- -------
> 2/12/2018 10:46:04 AM 603 Started deployment Register
> operation on a package with main parameter:
> AppxManifest.xml and Options: DevelopmentModeOption. See
> http://go.microsoft.com/fwlink/?LinkId=235160
> <http://go.microsoft.com/fwlink/?LinkId=235160> for help
> diagnosing app
> deployment issues.
> 2/12/2018 10:46:04 AM 10002 Creating Resiliency File
> C:\ProgramData\Microsoft\Windows\AppRepository\0e4badcc
> -4375-4273-8437-a272b775a415_S-1-5-21-582946636-1726034447-2572216908-1005_1.rsl
> c for Register Operation on Package
> JDK8189938_1.0.0.0_x64__hz258y3tkez3a.
> 2/12/2018 10:46:04 AM 607 Deployment Register
> operation on package JDK8189938_1.0.0.0_x64__hz258y3tkez3a
> has been de-queued and is running for user SID
> S-1-5-21-582946636-1726034447-2572216908-1005.
> 2/12/2018 10:46:04 AM 613 Adding uri to the list of Uris:
> D:\prasanta\bug8189938\JDK-8189938-master\dist\appx\AppxManifest.xml.
> 2/12/2018 10:46:05 AM 492 In-place package update
> policy result for JDK8189938_1.0.0.0_x64__hz258y3tkez3a
> - staging: false, applying false
> 2/12/2018 10:46:05 AM 468 error 0x80070005: Failed to
> set access rights to appx.
> 2/12/2018 10:46:05 AM 605 The last successful state
> reached was PreStagePackagesInUseClosed. Failure
> occurred before reaching the next state Staged. hr:
> 0x80070005
> 2/12/2018 10:46:05 AM 401 Deployment Register
> operation with target volume C: on Package
> JDK8189938_1.0.0.0_x64__hz258y3tkez3a from: (AppxManifest.xml)
> failed with
> error 0x80070005. See
> http://go.microsoft.com/fwlink/?LinkId=235160
> <http://go.microsoft.com/fwlink/?LinkId=235160> for help
> diagnosing app deployment issues.
> 2/12/2018 10:46:05 AM 404 AppX Deployment operation
> failed for package
> JDK8189938_1.0.0.0_x64__hz258y3tkez3a with error 0x80070005. The
> specific error
> text for this failure is: Deployment Register operation
> with target volume C:
> on Package JDK8189938_1.0.0.0_x64__hz258y3tkez3a from:
> (AppxManifest.xml)
> failed with error 0x80070005. See
> http://go.microsoft.com/fwlink/?LinkId=235160
> <http://go.microsoft.com/fwlink/?LinkId=235160>
> for help diagnosing app deployment issues.
> PS D:\prasanta\bug8189938\JDK-8189938-master>
>
> Regards
> Prasanta
> On 2/9/2018 9:28 PM, Reinhard Pointner wrote:
>> Hi Prasanta,
>>
>> Thanks for looking into this issue. When doing Windows
>> development, the Event Log is sometimes quite useful. The error
>> output hints at some additional information in the Windows Event
>> Log. Have you had a look to see if there's any hints as to why
>> it's not working on your test machine?
>>
>> >> NOTE: For additional information, look for *[ActivityId]
>> 02867602-9e78-0006-8ffb-8802789ed301 in the Event Log* or use the
>> command line *Get-AppxLog -ActivityID
>> 02867602-9e78-0006-8ffb-8802789ed301*
>> *
>> *
>> Kind Regards,
>> Reinhard
>>
>> On 9 February 2018 at 16:23, Prasanta Sadhukhan
>> <prasanta.sadhukhan at oracle.com
>> <mailto:prasanta.sadhukhan at oracle.com>> wrote:
>>
>> Hi Reinhard,
>>
>> Yes, I was running as a Administrator. But, I created another
>> Standard user and login through that but I still get the same
>> problem.
>>
>> Regards
>> Prasanta
>> On 2/9/2018 12:09 PM, Reinhard Pointner wrote:
>>> Dear Prasanta,
>>>
>>> The ant script calls the Add-AppxPackage function and fails
>>> with this error message:
>>> "Add-AppxPackage : Deployment failed with HRESULT:
>>> 0x80070005, Access is denied."
>>>
>>> Are you running CMD / PowerShell as Administrator? I search
>>> for this error message on Google, and I found a few results
>>> were running as normal user (and not as Administrator)
>>> solved the issue. I've tried again myself as well, and I can
>>> easily reproduce the issue on a newly factory reset Windows
>>> 10 machine with the latest updates running the build via CMD
>>> as my normal user.
>>>
>>> Greetings,
>>> Reinhard
>>>
>>> On 9 February 2018 at 12:58,
>>> <swing-dev-request at openjdk.java.net
>>> <mailto:swing-dev-request at openjdk.java.net>> wrote:
>>>
>>> Send swing-dev mailing list submissions to
>>> swing-dev at openjdk.java.net
>>> <mailto:swing-dev at openjdk.java.net>
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> http://mail.openjdk.java.net/mailman/listinfo/swing-dev
>>> <http://mail.openjdk.java.net/mailman/listinfo/swing-dev>
>>> or, via email, send a message with subject or body 'help' to
>>> swing-dev-request at openjdk.java.net
>>> <mailto:swing-dev-request at openjdk.java.net>
>>>
>>> You can reach the person managing the list at
>>> swing-dev-owner at openjdk.java.net
>>> <mailto:swing-dev-owner at openjdk.java.net>
>>>
>>> When replying, please edit your Subject line so it is
>>> more specific
>>> than "Re: Contents of swing-dev digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>> 1. Re: JDK-8189938: Proposed patch (Semyon Sadetsky)
>>> 2. Re: JDK-8189938: Proposed patch (Matthias Bl?sing)
>>> 3. Re: JDK-8189938: Proposed patch (Sergey Bylokhov)
>>> 4. Re: JDK-8189938: Proposed patch (Semyon Sadetsky)
>>> 5. Re: JDK-8189938: Proposed patch (Prasanta Sadhukhan)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Thu, 8 Feb 2018 12:06:04 -0800
>>> From: Semyon Sadetsky <semyon.sadetsky at oracle.com
>>> <mailto:semyon.sadetsky at oracle.com>>
>>> To: Matthias Bl?sing <mblaesing at doppel-helix.eu
>>> <mailto:mblaesing at doppel-helix.eu>>,
>>> swing-dev at openjdk.java.net
>>> <mailto:swing-dev at openjdk.java.net>
>>> Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
>>> Message-ID:
>>> <31b2fba0-07dc-3a21-9aab-c19c980df142 at oracle.com
>>> <mailto:31b2fba0-07dc-3a21-9aab-c19c980df142 at oracle.com>>
>>> Content-Type: text/plain; charset=utf-8; format=flowed
>>>
>>> Yet another question. Do you know what might call
>>> CoInitialize in a
>>> different mode? It looks like we use STA everywhere in JDK.
>>>
>>> --Semyon
>>>
>>>
>>> On 02/08/2018 11:55 AM, Semyon Sadetsky wrote:
>>> > I meant the case when MTA COM service is actually
>>> used, it might cause
>>> > issues since the JDK code invokes an another API which
>>> assumes
>>> > synchronization. At least performance may be affected.
>>> >
>>> > We don't do separate testing of JDK in MTA mode
>>> especially on the
>>> > regular base. That is why I wouldn't consider MTA mode
>>> as supported.
>>> >
>>> > So, before push the change I would make sure of the
>>> regression test
>>> > suite run in MTA mode hasn't brought any surprises.
>>> >
>>> > --Semyon
>>> >
>>> > On 02/08/2018 11:18 AM, Matthias Bl?sing wrote:
>>> >
>>> >> Resend: I accidentally dropped swing-dev from
>>> receivers (@Semyon I'm
>>> >> subscribed to swing-dev, so we could direct the mails
>>> to the
>>> >> mailinglist)
>>> >>
>>> >>
>>> >> Hey Semyon,
>>> >>
>>> >> Am Donnerstag, den 08.02.2018, 10:52 -0800 schrieb
>>> Semyon Sadetsky:
>>> >>> Since you are suggesting to switch from STA to MTA which
>>> >>> consequences
>>> >>> will it have to the current JDK code that was
>>> written to support STA
>>> >>> only?
>>> >> I think there are two questions hidden here:
>>> >>
>>> >> === How does this affect the common codepath taken
>>> today? ===
>>> >>
>>> >> It does not. It only changes the behaviour if
>>> CoInitalize fails. So
>>> >> behavioural changes can only occur in environments
>>> that did not work
>>> >> previously.
>>> >>
>>> >> Before this changeset:
>>> >>
>>> >> ? * CoInitialize works => The ShellFolder code can be
>>> used as is
>>> >> ? * CoInitialize failes => The ShellFolder code
>>> raises an exception
>>> >>
>>> >> After this changeset:
>>> >>
>>> >> ? * CoInitialize works => The ShellFolder code can be
>>> used as is
>>> >> ? * CoInitialize failes => retry CoInitializeEx with
>>> multi-threaded
>>> >> ??? apartment
>>> >> ? * if CoInitializeEx fails for multi-threaded
>>> apartment raise exception
>>> >> ??? as before
>>> >>
>>> >> === Is it expected to cause problems in the new code
>>> path? ====
>>> >>
>>> >> My understanding of STA vs. MTA is, that it only
>>> affects calls from
>>> >> native to java and not the other way round.
>>> >>
>>> >> To get calls from outside you'd need to install a
>>> callback. My
>>> >> understanding is, that you'd need to use an
>>> IConnectionPoint and call
>>> >> its Advise method. I did not spot any such methods.
>>> >>
>>> >> So while I did not go through the whole code base, I
>>> think this
>>> >> changeset should be save.
>>> >>
>>> >> Greetings
>>> >>
>>> >> Matthias
>>> >>
>>> >>> On 02/08/2018 10:32 AM, Matthias Bl?sing wrote:
>>> >>>> referring to this bug:
>>> >>>>
>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8189938
>>> <https://bugs.openjdk.java.net/browse/JDK-8189938>
>>> >>>>
>>> >>>> With the instructions given in:
>>> >>>>
>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8193928
>>> <https://bugs.openjdk.java.net/browse/JDK-8193928>
>>> (closed as
>>> >>>> duplicate of JDK-8189938)
>>> >>>>
>>> >>>> I was able to reproduce the problem on a clean
>>> Windows 10
>>> >>>> Installation,
>>> >>>> as described in the initial report.
>>> >>>>
>>> >>>> The resulting exception leads to my proposed fix:
>>> >>>>
>>> >>>> ????????? Could not initialize COM: HRESULT=0x80010106
>>> >>>>
>>> >>>> That HRESULT translates to: RPC_E_CHANGED_MODE
>>> >>>>
>>> >>>> This means, that the COM subsystem is already
>>> initialized, but with
>>> >>>> a
>>> >>>> different mode. The code uses CoInitialize and this
>>> initializes the
>>> >>>> threading module to be apartment threaded. The
>>> above HRESULT means
>>> >>>> the
>>> >>>> thread was already initialized to be multi-threaded.
>>> >>>>
>>> >>>> The mode can't be changed after is was set once, so
>>> instead of
>>> >>>> bailing
>>> >>>> out, I suggest to accept the situation and
>>> initialize to be multi-
>>> >>>> threaded.
>>> >>>>
>>> >>>> The consequence is that calls from COM to Java
>>> could end up on the
>>> >>>> wrong thread. A quick look through the code
>>> suggest, that COM
>>> >>>> advises
>>> >>>> are not used, so this is a risk that should be taken.
>>> >>>>
>>> >>>> The fix in this case works like this:
>>> >>>>
>>> >>>> ?? * try to initialize COM as it was
>>> >>>> ?? * check the return
>>> >>>> ?? * if it is RPC_E_CHANGED_MODE, retry
>>> initialization als multi-
>>> >>>> threaded
>>> >>>> ?? * only if that fails raise an exception
>>> >
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Thu, 08 Feb 2018 22:19:51 +0100
>>> From: Matthias Bl?sing <mblaesing at doppel-helix.eu
>>> <mailto:mblaesing at doppel-helix.eu>>
>>> To: Semyon Sadetsky <semyon.sadetsky at oracle.com
>>> <mailto:semyon.sadetsky at oracle.com>>,
>>> swing-dev at openjdk.java.net
>>> <mailto:swing-dev at openjdk.java.net>
>>> Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
>>> Message-ID: <1518124791.13185.19.camel at doppel-helix.eu
>>> <mailto:1518124791.13185.19.camel at doppel-helix.eu>>
>>> Content-Type: text/plain; charset="UTF-8"
>>>
>>> Hi,
>>>
>>> Am Donnerstag, den 08.02.2018, 12:06 -0800 schrieb
>>> Semyon Sadetsky:
>>> > Yet another question. Do you know what might call
>>> CoInitialize in a
>>> > different mode? It looks like we use STA everywhere in
>>> JDK.
>>>
>>> I tried to find some documentation how the
>>> FullTrustProcessLauncher of
>>> an UWP application works, but while the MSDN full of
>>> documentation
>>> about UWP, the lifecycle of a native application seems
>>> not to be
>>> covered. But my suspicion is this: The launching of an
>>> APPX package
>>> involves the runtime system creating an environment for
>>> the application
>>> and that seems to rely heavily on COM.
>>>
>>> So I assume, that COM is initialized outside the java
>>> core and the java
>>> process get this inherited. (But this is speculation!).
>>>
>>> I base this on the fact, that CoInitializeEx succeeds
>>> and multi
>>> threaded, but fails appartment threaded and the JDK code
>>> holds exactly
>>> three files calling CoInitialize (D2DPipelineManager.cpp,
>>> ShellFolder2.cpp, PLATFORM_API_WinOS_DirectSound.cpp).
>>>
>>> > On 02/08/2018 11:55 AM, Semyon Sadetsky wrote:
>>> > > I meant the case when MTA COM service is actually
>>> used, it might cause
>>> > > issues since the JDK code invokes an another API
>>> which assumes
>>> > > synchronization. At least performance may be affected.
>>> > >
>>> > > We don't do separate testing of JDK in MTA mode
>>> especially on the
>>> > > regular base. That is why I wouldn't consider MTA
>>> mode as supported.
>>> > >
>>> > > So, before push the change I would make sure of the
>>> regression test
>>> > > suite run in MTA mode hasn't brought any surprises.
>>>
>>> Aggreed and I'd like to help you, but in fact I was
>>> happy, that I
>>> managed to compile the JDK on windows and I have zero
>>> experience
>>> working on the JDK sources.
>>>
>>> As an observation: The COM initialization and usage
>>> looked pretty tight
>>> together in the sources and at least initialization
>>> happens only in the
>>> three files mentioned above. The DirectSound part is
>>> even limit to a
>>> small thread. The ShellFolder2 code looks to be the
>>> biggest direct
>>> user.
>>>
>>> Greetings,
>>> Matthias
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 3
>>> Date: Thu, 8 Feb 2018 13:58:32 -0800
>>> From: Sergey Bylokhov <Sergey.Bylokhov at oracle.com
>>> <mailto:Sergey.Bylokhov at oracle.com>>
>>> To: Matthias Bl?sing <mblaesing at doppel-helix.eu
>>> <mailto:mblaesing at doppel-helix.eu>>,
>>> swing-dev at openjdk.java.net
>>> <mailto:swing-dev at openjdk.java.net>
>>> Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
>>> Message-ID:
>>> <340b2b22-4f83-4f16-18bf-7bca181c85ab at oracle.com
>>> <mailto:340b2b22-4f83-4f16-18bf-7bca181c85ab at oracle.com>>
>>> Content-Type: text/plain; charset=utf-8; format=flowed
>>>
>>> Hi, Matthias.
>>> Did you have a chance to find why this code works on
>>> jdk8u152(this is
>>> reported in the bug description).
>>>
>>> On 08/02/2018 10:32, Matthias Bl?sing wrote:
>>> > Hi all,
>>> >
>>> > last month I saw the message from Reinhard Pointer on
>>> this list:
>>> >
>>> >
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2018-January/008132.html
>>> <http://mail.openjdk.java.net/pipermail/swing-dev/2018-January/008132.html>
>>> >
>>> > referring to this bug:
>>> >
>>> > https://bugs.openjdk.java.net/browse/JDK-8189938
>>> <https://bugs.openjdk.java.net/browse/JDK-8189938>
>>> >
>>> > With the instructions given in:
>>> >
>>> > https://bugs.openjdk.java.net/browse/JDK-8193928
>>> <https://bugs.openjdk.java.net/browse/JDK-8193928>
>>> (closed as duplicate of JDK-8189938)
>>> >
>>> > I was able to reproduce the problem on a clean Windows
>>> 10 Installation,
>>> > as described in the initial report.
>>> >
>>> > The resulting exception leads to my proposed fix:
>>> >
>>> > Could not initialize COM: HRESULT=0x80010106
>>> >
>>> > That HRESULT translates to: RPC_E_CHANGED_MODE
>>> >
>>> > This means, that the COM subsystem is already
>>> initialized, but with a
>>> > different mode. The code uses CoInitialize and this
>>> initializes the
>>> > threading module to be apartment threaded. The above
>>> HRESULT means the
>>> > thread was already initialized to be multi-threaded.
>>> >
>>> > The mode can't be changed after is was set once, so
>>> instead of bailing
>>> > out, I suggest to accept the situation and initialize
>>> to be multi-
>>> > threaded.
>>> >
>>> > The consequence is that calls from COM to Java could
>>> end up on the
>>> > wrong thread. A quick look through the code suggest,
>>> that COM advises
>>> > are not used, so this is a risk that should be taken.
>>> >
>>> > The fix in this case works like this:
>>> >
>>> > * try to initialize COM as it was
>>> > * check the return
>>> > * if it is RPC_E_CHANGED_MODE, retry initialization
>>> als multi-threaded
>>> > * only if that fails raise an exception
>>> >
>>> > One could argue, that if COM is already initialized,
>>> you don't need to
>>> > do it yourself, but documentation states, that every
>>> successful call to
>>> > CoInitialize/CoInitializeEx must be paired with
>>> CoUninitialize.
>>> >
>>> > D3DPipelineManager tracks this in bComInitialized, the
>>> other two
>>> > callers in the JDK are:
>>> >
>>> > - PLATFORM_API_WinOS_DirectSound.cpp
>>> > - ShellFolder2.cpp
>>> >
>>> > Both are covered in the patches. For ShellFolder2
>>> there is an
>>> > initialization check, this is modified as described
>>> above. And if both
>>> > initialization variant (apartment threaded and multi
>>> threaded fail)
>>> > this raises an exception.
>>> >
>>> > PLATFORM_API_WinOS_DirectSound is slightly different.
>>> The fallback in
>>> > the initialization is still done, but no exception is
>>> raised in the
>>> > error case. This follows the code flow before this change.
>>> >
>>> > I attached the diffs against JDK10 and JDK9 to this
>>> email. If they are
>>> > stripped, they can be found here:
>>> >
>>> > http://www.doppel-helix.eu/JDK8189938-openjdk9.diff
>>> <http://www.doppel-helix.eu/JDK8189938-openjdk9.diff>
>>> > http://www.doppel-helix.eu/JDK8189938-openjdk10.diff
>>> <http://www.doppel-helix.eu/JDK8189938-openjdk10.diff>
>>> >
>>> > I hope this helps with a fix.
>>> >
>>> > Greetings
>>> >
>>> > Matthias
>>> >
>>>
>>>
>>> --
>>> Best regards, Sergey.
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 4
>>> Date: Thu, 8 Feb 2018 14:42:12 -0800
>>> From: Semyon Sadetsky <semyon.sadetsky at oracle.com
>>> <mailto:semyon.sadetsky at oracle.com>>
>>> To: Matthias Bl?sing <mblaesing at doppel-helix.eu
>>> <mailto:mblaesing at doppel-helix.eu>>,
>>> swing-dev at openjdk.java.net
>>> <mailto:swing-dev at openjdk.java.net>, Prasanta Sadhukhan
>>> <prasanta.sadhukhan at oracle.com
>>> <mailto:prasanta.sadhukhan at oracle.com>>
>>> Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
>>> Message-ID:
>>> <d6211787-1e9f-4a11-8e40-bc7a5083e441 at oracle.com
>>> <mailto:d6211787-1e9f-4a11-8e40-bc7a5083e441 at oracle.com>>
>>> Content-Type: text/plain; charset=utf-8; format=flowed
>>>
>>> On 02/08/2018 01:19 PM, Matthias Bl?sing wrote:
>>>
>>> > Hi,
>>> >
>>> > Am Donnerstag, den 08.02.2018, 12:06 -0800 schrieb
>>> Semyon Sadetsky:
>>> >> Yet another question. Do you know what might call
>>> CoInitialize in a
>>> >> different mode? It looks like we use STA everywhere
>>> in JDK.
>>> > I tried to find some documentation how the
>>> FullTrustProcessLauncher of
>>> > an UWP application works, but while the MSDN full of
>>> documentation
>>> > about UWP, the lifecycle of a native application seems
>>> not to be
>>> > covered. But my suspicion is this: The launching of an
>>> APPX package
>>> > involves the runtime system creating an environment
>>> for the application
>>> > and that seems to rely heavily on COM.
>>> It looks like there is an internal reason. Probably for
>>> UWP apps only
>>> MTA is allowed because of their life-cycle (the app may
>>> be suspended).
>>> > So I assume, that COM is initialized outside the java
>>> core and the java
>>> > process get this inherited. (But this is speculation!).
>>> >
>>> > I base this on the fact, that CoInitializeEx succeeds
>>> and multi
>>> > threaded, but fails appartment threaded and the JDK
>>> code holds exactly
>>> > three files calling CoInitialize (D2DPipelineManager.cpp,
>>> > ShellFolder2.cpp, PLATFORM_API_WinOS_DirectSound.cpp).
>>> >
>>> >> On 02/08/2018 11:55 AM, Semyon Sadetsky wrote:
>>> >>> I meant the case when MTA COM service is actually
>>> used, it might cause
>>> >>> issues since the JDK code invokes an another API
>>> which assumes
>>> >>> synchronization. At least performance may be affected.
>>> >>>
>>> >>> We don't do separate testing of JDK in MTA mode
>>> especially on the
>>> >>> regular base. That is why I wouldn't consider MTA
>>> mode as supported.
>>> >>>
>>> >>> So, before push the change I would make sure of the
>>> regression test
>>> >>> suite run in MTA mode hasn't brought any surprises.
>>> > Aggreed and I'd like to help you, but in fact I was
>>> happy, that I
>>> > managed to compile the JDK on windows and I have zero
>>> experience
>>> > working on the JDK sources.
>>> Prasanta,
>>>
>>> since the bug is assigned to you can you test the
>>> suggested fix in MTA
>>> mode and sponsor it if there are no issues?
>>>
>>> --Semyon
>>> >
>>> > As an observation: The COM initialization and usage
>>> looked pretty tight
>>> > together in the sources and at least initialization
>>> happens only in the
>>> > three files mentioned above. The DirectSound part is
>>> even limit to a
>>> > small thread. The ShellFolder2 code looks to be the
>>> biggest direct
>>> > user.
>>> >
>>> > Greetings,
>>> > Matthias
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 5
>>> Date: Fri, 9 Feb 2018 11:24:30 +0530
>>> From: Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com
>>> <mailto:prasanta.sadhukhan at oracle.com>>
>>> To: Semyon Sadetsky <semyon.sadetsky at oracle.com
>>> <mailto:semyon.sadetsky at oracle.com>>, Matthias Bl?sing
>>> <mblaesing at doppel-helix.eu
>>> <mailto:mblaesing at doppel-helix.eu>>,
>>> swing-dev at openjdk.java.net
>>> <mailto:swing-dev at openjdk.java.net>
>>> Subject: Re: <Swing Dev> JDK-8189938: Proposed patch
>>> Message-ID:
>>> <ee194e8a-4995-e80d-cd06-75bac3843c1d at oracle.com
>>> <mailto:ee194e8a-4995-e80d-cd06-75bac3843c1d at oracle.com>>
>>> Content-Type: text/plain; charset=utf-8; format=flowed
>>>
>>> Hi,
>>>
>>>
>>> On 2/9/2018 4:12 AM, Semyon Sadetsky wrote:
>>> > On 02/08/2018 01:19 PM, Matthias Bl?sing wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> Am Donnerstag, den 08.02.2018, 12:06 -0800 schrieb
>>> Semyon Sadetsky:
>>> >>> Yet another question. Do you know what might call
>>> CoInitialize in a
>>> >>> different mode? It looks like we use STA everywhere
>>> in JDK.
>>> >> I tried to find some documentation how the
>>> FullTrustProcessLauncher of
>>> >> an UWP application works, but while the MSDN full of
>>> documentation
>>> >> about UWP, the lifecycle of a native application
>>> seems not to be
>>> >> covered. But my suspicion is this: The launching of
>>> an APPX package
>>> >> involves the runtime system creating an environment
>>> for the application
>>> >> and that seems to rely heavily on COM.
>>> > It looks like there is an internal reason. Probably
>>> for UWP apps only
>>> > MTA is allowed because of their life-cycle (the app
>>> may be suspended).
>>> >> So I assume, that COM is initialized outside the java
>>> core and the java
>>> >> process get this inherited. (But this is speculation!).
>>> >>
>>> >> I base this on the fact, that CoInitializeEx succeeds
>>> and multi
>>> >> threaded, but fails appartment threaded and the JDK
>>> code holds exactly
>>> >> three files calling CoInitialize (D2DPipelineManager.cpp,
>>> >> ShellFolder2.cpp, PLATFORM_API_WinOS_DirectSound.cpp).
>>> >>
>>> >>> On 02/08/2018 11:55 AM, Semyon Sadetsky wrote:
>>> >>>> I meant the case when MTA COM service is actually
>>> used, it might cause
>>> >>>> issues since the JDK code invokes an another API
>>> which assumes
>>> >>>> synchronization. At least performance may be affected.
>>> >>>>
>>> >>>> We don't do separate testing of JDK in MTA mode
>>> especially on the
>>> >>>> regular base. That is why I wouldn't consider MTA
>>> mode as supported.
>>> >>>>
>>> >>>> So, before push the change I would make sure of the
>>> regression test
>>> >>>> suite run in MTA mode hasn't brought any surprises.
>>> >> Aggreed and I'd like to help you, but in fact I was
>>> happy, that I
>>> >> managed to compile the JDK on windows and I have zero
>>> experience
>>> >> working on the JDK sources.
>>> > Prasanta,
>>> >
>>> > since the bug is assigned to you can you test the
>>> suggested fix in MTA
>>> > mode and sponsor it if there are no issues?
>>> >
>>> I am still not able to reproduce in our WIndows 10 Pro
>>> (EN-W10P64-10.0.01.0). "Developer Mode" and "execute
>>> powershell script"
>>> is enabled. This is what I am getting
>>> $ ant clean appx install
>>> Buildfile: D:\prasanta\8189938\JDK-8189938-master\build.xml
>>>
>>> clean:
>>> ?? [delete] Deleting directory
>>> D:\prasanta\8189938\JDK-8189938-master\bin
>>> ?? [delete] Deleting directory
>>> D:\prasanta\8189938\JDK-8189938-master\dist\appx
>>> ??? [mkdir] Created dir:
>>> D:\prasanta\8189938\JDK-8189938-master\bin
>>> ??? [mkdir] Created dir:
>>> D:\prasanta\8189938\JDK-8189938-master\dist\appx
>>>
>>> build:
>>> ??? [javac] Compiling 1 source file to
>>> D:\prasanta\8189938\JDK-8189938-master\bin
>>> ??? [javac] warning: [options] bootstrap class path not
>>> set in
>>> conjunction with -source 9
>>> ??? [javac] 1 warning
>>> ????? [jar] Building jar:
>>> D:\prasanta\8189938\JDK-8189938-master\dist\appx\main.jar
>>>
>>> appx:
>>> ???? [copy] Copying 5 files to
>>> D:\prasanta\8189938\JDK-8189938-master\dist\appx
>>> ???? [exec] Expected SHA256 checksum:
>>> ffcd6d774cfba78d88a1af253eecad0ec3639bdeabdfb3345e61d1c2355267a4
>>> ???? [exec] Actual SHA256 checksum:
>>> ffcd6d774cfba78d88a1af253eecad0ec3639bdeabdfb3345e61d1c2355267a4
>>> ???? [exec] Download complete:
>>> jre-9.0.4_windows-x64_bin.tar.gz
>>> ??? [untar] Expanding:
>>> D:\prasanta\8189938\JDK-8189938-master\jre-9.0.4_windows-x64_bin.tar.gz
>>> into D:\prasanta\8189938\JDK-8189938-master\dist\appx\jre
>>>
>>> install:
>>> ???? [exec] Add-AppxPackage : Deployment failed with
>>> HRESULT:
>>> 0x80070005, Access is denied.
>>> ???? [exec] Deployment Register operation with target
>>> volume C: on
>>> Package JDK8189938_1.0.0.0_x64__hz258y3tkez3a from:
>>> ???? [exec] (AppxManifest.xml)? failed with error
>>> 0x80070005. See
>>> http://go.microsoft.com/fwlink/?LinkId=235160
>>> <http://go.microsoft.com/fwlink/?LinkId=235160> for help
>>> ???? [exec] diagnosing app deployment issues.
>>> ???? [exec] NOTE: For additional information, look for
>>> [ActivityId]
>>> 02867602-9e78-0006-8ffb-8802789ed301 in the Event Log or use
>>> ???? [exec] the command line Get-AppxLog -ActivityID
>>> 02867602-9e78-0006-8ffb-8802789ed301
>>> ???? [exec] At line:1 char:1
>>> ???? [exec] + Add-AppxPackage -Register
>>> dist/appx/AppxManifest.xml
>>> ???? [exec] +
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> ???? [exec]???? + CategoryInfo????????? : SecurityError:
>>> (D:\prasanta\818...ppxManifest.xml:String)
>>> [Add-AppxPackage], PSSecurityE
>>> ???? [exec]??? xception
>>> ???? [exec]???? + FullyQualifiedErrorId :
>>> DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.AddAppxPackageCommand
>>> ???? [exec]
>>> ???? [exec] Result: 1
>>>
>>> BUILD SUCCESSFUL
>>> Total time: 6 seconds
>>>
>>> ARAPTE-PC+client at ARAPTE-PC
>>> /cygdrive/d/prasanta/8189938/JDK-8189938-master
>>> $ ls
>>> appx? bin? build.xml? dist? get-java.ps1
>>> jre-9.0.4_windows-x64_bin.tar.gz? LICENSE? README.md
>>> screenshot.png? src
>>>
>>> ARAPTE-PC+client at ARAPTE-PC
>>> /cygdrive/d/prasanta/8189938/JDK-8189938-master
>>> $ JDK8189938
>>> bash: JDK8189938: command not found
>>>
>>> Regards
>>> Prasanta
>>> > --Semyon
>>> >>
>>> >> As an observation: The COM initialization and usage
>>> looked pretty tight
>>> >> together in the sources and at least initialization
>>> happens only in the
>>> >> three files mentioned above. The DirectSound part is
>>> even limit to a
>>> >> small thread. The ShellFolder2 code looks to be the
>>> biggest direct
>>> >> user.
>>> >>
>>> >> Greetings,
>>> >> Matthias
>>> >
>>>
>>>
>>>
>>> End of swing-dev Digest, Vol 130, Issue 13
>>> ******************************************
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20180212/40b68afd/attachment.html>
More information about the swing-dev
mailing list