search

hluk / CopyQ

Clipboard manager with advanced features
GNU General Public License v3.0
8.52k stars 439 forks source link

Error issued at system shutdown #1249

Open Gitoffthelawn opened 4 years ago

Gitoffthelawn commented 4 years ago

When shutting down Windows, CopyQ issues the following message is displayed:

Command “copyq onExit”
Error: Process crashed

Upon looking at CopyQ's log, I see

Note [2019-11-01 20:03:38.534] <Server-2228>: Command “copyq --clipboard-access monitorClipboard”
Note [2019-11-01 20:03:38.534] <Server-2228>:    Error: Process crashed
Note [2019-11-01 20:03:38.534] <Server-2228>:    1. copyq --clipboard-access monitorClipboard
Note [2019-11-01 20:09:47.941] <Server-2208>: Command “copyq --clipboard-access monitorClipboard”
Note [2019-11-01 20:09:47.941] <Server-2208>:    Error: Process crashed
Note [2019-11-01 20:09:47.941] <Server-2208>:    1. copyq --clipboard-access monitorClipboard
Note [2019-11-01 20:09:48.003] <Server-2208>: Command “copyq --clipboard-access monitorClipboard”
Note [2019-11-01 20:09:48.003] <Server-2208>:    Error: Process crashed
Note [2019-11-01 20:09:48.003] <Server-2208>:    1. copyq --clipboard-access monitorClipboard
Note [2019-11-01 20:09:50.172] <Server-2208>: Command “copyq onExit”
Note [2019-11-01 20:09:50.172] <Server-2208>:    Error: Process crashed
Note [2019-11-01 20:09:50.172] <Server-2208>:    1. copyq onExit
Note [2019-11-01 20:09:50.218] <Server-2208>: Command “copyq onExit”
Note [2019-11-01 20:09:50.218] <Server-2208>:    Error: Process crashed
Note [2019-11-01 20:09:50.218] <Server-2208>:    1. copyq onExit

The system was turned off and restarted twice during that time.

It looks like one error might be happening when Windows starts (CopyQ is run on startup), and another when Windows is shut down.

I do have CopyQ syncing with an empty sync path to clear the CopyQ data between reboots (see https://github.com/hluk/CopyQ/issues/1063).

Version, OS and Environment

hluk commented 4 years ago

Looks like Qt can emit aboutToExit signal multiple times. I'm fixing this.

Thanks for the report.

Gitoffthelawn commented 4 years ago

You're welcome. Thanks for the fix!

Gitoffthelawn commented 4 years ago

Thanks for trying to fix this.

I think the error on startup is now fixed in v3.9.3, but the error on shutdown persists (same exact error in the log).

hluk commented 4 years ago

I think the error on startup is now fixed in v3.9.3, but the error on shutdown persists (same exact error in the log).

Hmm, are you sure the errors are from recent run with the updated version and not from an old CopyQ version?

Gitoffthelawn commented 4 years ago

Unfortunately, yes. I just tested it again a moment ago, and the issue persists. :( Sorry!

Gitoffthelawn commented 4 years ago

This issue, unfortunately, needs to be reopened. Still getting this error on every Windows shutdown:

Command “copyq --clipboard-access monitorClipboard”
Error: Process crashed
1. copyq --clipboard-access monitorClipboard
hluk commented 4 years ago

@Gitoffthelawn Can you provide copyq version output?

Gitoffthelawn commented 4 years ago

Yes. It took me a little bit to figure out how to do it, but I got it! :)

CopyQ Clipboard Manager v3.10.0
Qt: 5.12.6
Compiler: GCC
Arch: i386-little_endian-ilp32
OS: Windows 7 SP 1 (6.1)
Gitoffthelawn commented 3 years ago

This note serves 3 purposes:

  1. To thank @hluk for the new version 4.0!
  2. To state that the crash on shutdown was still occurring with v3.13.0
  3. To let you know that I'll be testing v4.0 very soon, and I'll let you know if that new version fixes the issue. :)
Gitoffthelawn commented 3 years ago

I completed testing of CopyQ v4.1. Overall, it's excellent. It does still issue the error on system shutdown (Win7 64-bit), however.

Gitoffthelawn commented 3 years ago

I noticed that the copyq version output I previously provided for you is now out of date. Here is the current output:

CopyQ Clipboard Manager v4.1.0
Qt: 5.15.2
KNotifications: 5.81.0
Compiler: MSVC
Arch: x86_64-little_endian-llp64
OS: Windows 7 Version 6.1 (SP 1)

I hope you are well. Except for this one crash bug on every shutdown, CopyQ is still working wonderfully.

Gitoffthelawn commented 2 years ago

CopyQ v6.1.0 seems to have the same issue of crashing during system shutdown.

I hoped to work around this issue by creating a scheduled task to automatically exit CopyQ during shutdown (and logoff) operations (by issuing the copyq exit command). Unfortunately, it didn't work. Here is the XML representation of the task I created:

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.3" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2021-07-15T04:00:00.000000</Date>
    <Author>GOTL</Author>
    <Description>Exit CopyQ when user logs out, which includes Windows shutdown.</Description>
  </RegistrationInfo>
  <Triggers>
    <SessionStateChangeTrigger>
      <Enabled>true</Enabled>
      <StateChange>ConsoleDisconnect</StateChange>
    </SessionStateChangeTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>GOTL</UserId>
      <LogonType>InteractiveToken</LogonType>
      <RunLevel>LeastPrivilege</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession>
    <UseUnifiedSchedulingEngine>false</UseUnifiedSchedulingEngine>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT1H</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <ShowMessage>
      <Title>Closing CopyQ</Title>
      <Body>Closing CopyQ so it does not crash during logout.</Body>
    </ShowMessage>
    <Exec>
      <Command>[path]\copyq.exe</Command>
      <Arguments>exit</Arguments>
      <WorkingDirectory>[path]</WorkingDirectory>
    </Exec>
  </Actions>
</Task>

I'm hopeful this bug can be fixed, or perhaps an effective workaround discovered.

hluk commented 2 years ago

So running copyq exit when not shutting down the system has the same effect?

Can you start CopyQ with debug logs enabled and share the messages logged on exit (F12 from main window to list the logs)?

Gitoffthelawn commented 2 years ago

So running copyq exit when not shutting down the system has the same effect?

Actually, copyq exit works perfectly when not shutting down the system.

I'm thinking my workaround isn't working correctly, but at this point, I'm not sure why.

The big question is why CopyQ crashes every time Windows shuts down. For some reason, it doesn't terminate properly when instructed by the OS.

IIRC, you don't have any Windows boxes for testing (please correct me if I'm not recalling accurately). If that's correct, do you test with a Windows VM running under Linux?

BTW, outside of this issue, CopyQ works great for me, and I'm always thankful to you for it.

hluk commented 2 years ago

IIRC, you don't have any Windows boxes for testing (please correct me if I'm not recalling accurately). If that's correct, do you test with a Windows VM running under Linux?

I haven't launched my Windows VM in a long time - but the usage is painful because of the constant intrusive updates and license-key breakages due to host system or virtualization software change. I don't think I have the time to set it up now.

Actually, copyq exit works perfectly when not shutting down the system.

I'm thinking my workaround isn't working correctly, but at this point, I'm not sure why.

After invoking the copyq exit some processes may be still finishing/terminating, I think Windows either forcefully closes them there is some problem when handling the close signal (which may be triggered only for the GUI process unfortunately).

hluk commented 2 years ago

I'm implementing some improvements for the exit handler. Can you test the development build with the fixes?

Gitoffthelawn commented 2 years ago

I'm implementing some improvements for the exit handler. Can you test the development build with the fixes?

Yes. Definitely. I'll have time to test it this weekend... already put it on my calendar.

Thanks for implementing some improvements... I'll write back as soon as I've performed testing.

Gitoffthelawn commented 2 years ago

I'm implementing some improvements for the exit handler. Can you test the development build with the fixes?

I finished testing. You did it! Excellent job Lukas! Thank you!

Are the artifacts from that build suitable for daily use? If so, I'll make the switch.

I noticed all the DLL files in the artifact's plugins folder are different from those in the official CopyQ 6.1.0 release. Are they good too? Any idea why they are different? I think I noticed this before with a previous artifact build.

I took a look at the CopyQ logs, and the items from v6.1.0.21 are:

CopyQ Warning <Server-xxxx>: [kf.windowsystem] QtWarning: Could not find any platform plugin
CopyQ Warning <Server-xxxx>: [default] QtWarning: QSystemTrayIcon::setVisible: No Icon set

Any thoughts on those log entries?

I also see quite a few incidences of this error in the log, but all of them were from before I tested v6.1.0.21:

CopyQ ERROR <Client-xxxx>: Cannot connect to server! Start CopyQ server first.

Any thoughts on that?

Thanks again for fixing this issue. I appreciate your efforts.

hluk commented 2 years ago

I finished testing. You did it! Excellent job Lukas! Thank you!

That's great to hear! \o/

Are the artifacts from that build suitable for daily use? If so, I'll make the switch.

Sure, the current development version should be pretty much stable.

I noticed all the DLL files in the artifact's plugins folder are different from those in the official CopyQ 6.1.0 release. Are they good too? Any idea why they are different? I think I noticed this before with a previous artifact build.

How different do you mean? The plugins are always rebuild with the app.

I took a look at the CopyQ logs, and the items from v6.1.0.21 are:

CopyQ Warning <Server-xxxx>: [kf.windowsystem] QtWarning: Could not find any platform plugin
CopyQ Warning <Server-xxxx>: [default] QtWarning: QSystemTrayIcon::setVisible: No Icon set

Any thoughts on those log entries?

These don't look important. I think I can fix the second one, but if the tray icon works fine, I do not see any issue with these.

I also see quite a few incidences of this error in the log, but all of them were from before I tested v6.1.0.21:

CopyQ ERROR <Client-xxxx>: Cannot connect to server! Start CopyQ server first.

Any thoughts on that?

This should popup in case a client process tries to send a message to the main GUI app which is not running. Should not be any issue.

Gitoffthelawn commented 2 years ago

That's great to hear! \o/

It always feels good to get things done earlier than expected!

Sure, the current development version should be pretty much stable.

Thanks.

How different do you mean? The plugins are always rebuild with the app.

A binary compare reveals differences. Were there changes to the plugins since v6.1.0?

...I think I can fix the second one...

Would you like me to create an issue report, or do you have it stored in your noggin?

This should popup in case a client process tries to send a message to the main GUI app which is not running. Should not be any issue.

Thanks. WFM.

Thank you again for the great cross-platform tool.

hluk commented 2 years ago

A binary compare reveals differences. Were there changes to the plugins since v6.1.0?

The plugins will always differ between builds because these are build again - the binaries from older builds are never reused.

Would you like me to create an issue report, or do you have it stored in your noggin?

Please feel free to create a new issue on GitHub.

Gitoffthelawn commented 2 years ago

The plugins will always differ between builds because these are build again - the binaries from older builds are never reused.

Thanks.

Please feel free to create a new issue on GitHub.

Done... see https://github.com/hluk/CopyQ/issues/1955

BTW, do you have a guesstimate of a date for the next official release that will include you patch for shutdown bug?

hluk commented 2 years ago

BTW, do you have a guesstimate of a date for the next official release that will include you patch for shutdown bug?

No estimate. I will try to release when I have time and if there are no critical issues.

Gitoffthelawn commented 2 years ago

@hluk For some reason, the CopyQ v6.2.0 release contains this bug again.

Gitoffthelawn commented 2 years ago

@hluk Would it be best to have this reopened?

hluk commented 2 years ago

Hmm, there were no changes in the code implemented in the last fix (976db6caf5872b96854f2d0be363b3216f565812) nor in any Windows specific code.

Can you share logs? Are there any other warnings or errors?

Gitoffthelawn commented 2 years ago

Hmm indeed.

The log contains hundreds of repetitions of:

Warning [timestamp] <Server-xxxx>: [kf.windowsystem] QtWarning: Could not find any platform plugin
Warning [timestamp] <Server-xxxx>: [default] QtWarning: QSystemTrayIcon::setVisible: No Icon set
Note [timestamp] <Server-xxxx>: Command “copyq --clipboard-access monitorClipboard”
Note [timestamp] <Server-xxxx>:    Error: Process crashed
Note [timestamp] <Server-xxxx>:    1. copyq --clipboard-access monitorClipboard

No other warnings or errors.