Open Gitoffthelawn opened 4 years ago
Looks like Qt can emit aboutToExit
signal multiple times. I'm fixing this.
Thanks for the report.
You're welcome. Thanks for the fix!
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).
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?
Unfortunately, yes. I just tested it again a moment ago, and the issue persists. :( Sorry!
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
@Gitoffthelawn Can you provide copyq version
output?
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)
This note serves 3 purposes:
I completed testing of CopyQ v4.1. Overall, it's excellent. It does still issue the error on system shutdown (Win7 64-bit), however.
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.
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.
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)?
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.
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).
I'm implementing some improvements for the exit handler. Can you test the development build with the fixes?
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.
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.
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.
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.
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.
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?
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.
@hluk For some reason, the CopyQ v6.2.0 release contains this bug again.
@hluk Would it be best to have this reopened?
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?
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.
When shutting down Windows, CopyQ issues the following message is displayed:
Upon looking at CopyQ's log, I see
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