Segmentation fault on exit in pyQt5 but not pyQt4 - crash

The workaround to a crash upon exit given in this answer works in pyqt4.
But not using pyqt5, where there is often (more than half the times) a segmentation fault.
Only the import lines changed
#!/usr/bin/python
import sys
#toolkit = "Qt4"
toolkit = "Qt5"
if toolkit == "Qt4":
# Qt4 (no crash)
from PyQt4.QtCore import *
from PyQt4.QtGui import *
elif toolkit == "Qt5":
# Qt5 (crash)
from PyQt5.QtWidgets import (
QApplication, QGraphicsScene, QGraphicsView
)
app = QApplication(sys.argv)
grview = QGraphicsView()
# no crash
scene = QGraphicsScene(parent=grview)
grview.setScene(scene)
grview.show()
sys.exit(app.exec_())
Here is the backtrace, from the core dump (as a side note, inside gdb, there is no crash)
[New LWP 4684]
[New LWP 4683]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `python grview_qt5.py'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f5233393e69 in ?? ()
(gdb) bt
#0 0x00007f5233393e69 in ()
#1 0x00007f522fee6f20 in ()
#2 0x0000000000e0d340 in ()
#3 0x00007f522fee6f20 in ()
#4 0x0000000000e0d5f0 in ()
#5 0x00007f523e0bc000 in _rtld_local () at /lib64/ld-linux-x86-64.so.2
#6 0x00007f523ae7285f in QThreadPrivate::start(void*) (arg=0xe0d340) at thread/qthread_unix.cpp:337
#7 0x00007f523d8780a4 in start_thread (arg=0x7f522fee7700) at pthread_create.c:309
#8 0x00007f523d5adcbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb) info threads
Id Target Id Frame
2 Thread 0x7f523e06f700 (LWP 4683) 0x00007f523deb21c7 in munmap () at ../sysdeps/unix/syscall-template.S:81
* 1 Thread 0x7f522fee7700 (LWP 4684) 0x00007f5233393e69 in ?? ()
Why the difference between pyqt4 and pyqt5 ?
It is surely related to Object Destruction on Exit, but how ?
What is the correct way to avoid this crash ?

I cannot make your example crash using Fedora 24's PyQt.
However I am also seeing this problem and do not have a definitive answer on how to clean up Qt objects before python exits. My app has 1000's of Qt objects and I'm not at all clear on hopw I will track down all the objects that fail to clean up.
I think the key is that you have to delete all the objects you have created in the reverse order of construction. Taking care to remove objects from any Qt object that has a reference to an other object. e.g widgets in a layout.
As I said in the comment the difference comes from changes from python2 to python3 to do with object deletion and garbage collection.
Using sys.exit() to avoid the clean up is not good enough.
You need to use os._exit( code ) which will prevent python from running onExit handlers. That is more likely to suppress the seg fault. But you will need to make sure that any important onExit handlers are run. For example to delete temp files.
Try exiting like this and see if for you the problem goes away.
grview.show()
rc = app.exec_()
del grview
del scene
del app
sys.exit( rc )

I had the same problem and just replacing sys.exit(wizard.exec_()) with os.exit(wizard.exec()) solved it for me.

Related

Laravel 6.10 Application works locally but fails on production server with "Target class [] does not exist."

This problem deals specifically with Laravel 6.10 and queue processing. On my local machine, the program runs fine, and all queued jobs load well and process to completion. On my GoDaddy server, I get a mysterious error when the job tries to load that reads:
Error thrown on line 805 in /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Container/Container.php with message:
Target class [] does not exist.
Trace:
#0 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Container/Container.php(681): Illuminate\Container\Container->build(NULL)
#1 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Container/Container.php(629): Illuminate\Container\Container->resolve(NULL, Array)
#2 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(776): Illuminate\Container\Container->make(NULL, Array)
#3 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Queue/Jobs/Job.php(215): Illuminate\Foundation\Application->make(NULL)
#4 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Queue/Jobs/Job.php(88): Illuminate\Queue\Jobs\Job->resolve(NULL)
#5 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(354): Illuminate\Queue\Jobs\Job->fire()
#6 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(300): Illuminate\Queue\Worker->process('database', Object(Illuminate\Queue\Jobs\DatabaseJob), Object(Illuminate\Queue\WorkerOptions))
#7 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(134): Illuminate\Queue\Worker->runJob(Object(Illuminate\Queue\Jobs\DatabaseJob), 'database', Object(Illuminate\Queue\WorkerOptions))
#8 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php(112): Illuminate\Queue\Worker->daemon('database', 'default', Object(Illuminate\Queue\WorkerOptions))
#9 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php(96): Illuminate\Queue\Console\WorkCommand->runWorker('database', 'default')
#10 [internal function]: Illuminate\Queue\Console\WorkCommand->handle()
#11 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(32): call_user_func_array(Array, Array)
#12 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Container/Util.php(36): Illuminate\Container\BoundMethod::Illuminate\Container\{closure}()
#13 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(90): Illuminate\Container\Util::unwrapIfClosure(Object(Closure))
#14 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(34): Illuminate\Container\BoundMethod::callBoundMethod(Object(Illuminate\Foundation\Application), Array, Object(Closure))
#15 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Container/Container.php(590): Illuminate\Container\BoundMethod::call(Object(Illuminate\Foundation\Application), Array, Array, NULL)
#16 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Console/Command.php(201): Illuminate\Container\Container->call(Array)
#17 /home/jaredclemence/public_html/theninjaassistant.com/vendor/symfony/console/Command/Command.php(255): Illuminate\Console\Command->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Illuminate\Console\OutputStyle))
#18 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Console/Command.php(188): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Illuminate\Console\OutputStyle))
#19 /home/jaredclemence/public_html/theninjaassistant.com/vendor/symfony/console/Application.php(1011): Illuminate\Console\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#20 /home/jaredclemence/public_html/theninjaassistant.com/vendor/symfony/console/Application.php(272): Symfony\Component\Console\Application->doRunCommand(Object(Illuminate\Queue\Console\WorkCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#21 /home/jaredclemence/public_html/theninjaassistant.com/vendor/symfony/console/Application.php(148): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#22 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Console/Application.php(93): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#23 /home/jaredclemence/public_html/theninjaassistant.com/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(131): Illuminate\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#24 /home/jaredclemence/public_html/theninjaassistant.com/artisan(37): Illuminate\Foundation\Console\Kernel->handle(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#25 {main}
I believe the problem starts and will be solved by fixing the trace at item #4 where the following is called: Illuminate\Queue\Jobs\Job->resolve(NULL). I see this in both failing jobs on the GoDaddy server, but it does not happen in local. I don't know enough about laravel to understand where the NULL value is coming from and how to fix it. This occurs before the job class is loaded, but it does not happen for all queued jobs. Only jobs of this class.
In both the local copy and the production copy I use the GoDaddy databases, so both systems talk to the same database host. I use a database named CMP_dev and CMP_core to differentiate between the development and production tables. Because I am using the same database source, I can rule out changes in the mysql settings.
I upgraded all composer packages and retested. Then, I committed the composer.lock file and updated the GoDaddy server to match. So, I can rule out problems with old buggy code that have already been fixed by someone else.
The PHP version on the server is 7.3.11, and the PHP version on local dev is 7.3.6. The good news is that they are both 7.3.X, which reduces risk of language variations, but there still may be an issue between 7.3.6 and 7.3.11, but GoDaddy does not allow me to control the PHP setting beyond the minor version number of 7.3.
---- Added on January 09, 2020------
I thought it might be the difference in web servers. On my local machine, I use php artisan serve to host the software. On GoDaddy, I use Nginx. However, then I realized that it is not the server that runs the queue. The command line runs the queue, and both commands are being run using php artisan schedule:run. This rules out the web server software and all its components.
---------
I have successfully run queued mail jobs, which means that the queue works. This should localize the issue to the two classes that are generating problems for me. If I can find the issue with one, I will likely find the issue with the second, so I will include the first job causing issue here:
app/Jobs/ConvertCsvFileToIntermediateFile.php:
namespace App\Jobs;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
use App\ContactCsvFile;
use Illuminate\Support\Facades\Log;
class ConvertCsvFileToIntermediateFile implements ShouldQueue
{
use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;
public $timeout = 500;
/** #var ContactCsvFile */
private $file;
private $delegate;
/**
* Create a new job instance.
*
* #return void
*/
public function __construct(ContactCsvFile $file, $delegate = null)
{
$this->file = $file;
$this->delegate = $delegate;
}
/**
* Execute the job.
*
* #return void
*/
public function handle()
{
$this->file->process($this->delegate);
}
}
The error is occurring before handle() is ever called. I know this because, when I include a dd($this->file) as the first line of handle, the line is never reached.
Also, I think it is important to note that when most jobs fail, their class name is listed in the queue:failed table. But in this case, the queue:failed table reads the time: "2020-01-08 09:23:23."
+----+------------+---------+---------------------+-----------+
| ID | Connection | Queue | Class | Failed At |
+----+------------+---------+---------------------+-----------+
| 2 | database | default | 2020-01-08 09:23:23 | |
+----+------------+---------+---------------------+-----------+
You have to read laravel 6.10 release notes.. Some functions deprecated and fixes.
I think you have to add php unit 9 instead of v8 not supported and add it to composer required not dev
I still do not know what the meaning of the error is or how to fix it. However, I found a way around the issue, which I will describe here in case it helps any others with this problem.
I began to suspect that the strange database entries that appeared in the queue:failed table were an indication that something terrible happened to cause the program to fail during execution, which maybe led to a partial write to the database. This does not make sense to me as a logical solution since I have the jobs running within a transaction that should roll back on failure.
That being said, I looked at a potential memory bloat issue and a timeout issue. I've been having trouble with the timeouts, but the classes are already set for public $timeout = 500;, which should guarantee a full 500 seconds before the job fails (These jobs were failing in less than one minute). Even though the class allows for 500 seconds, GoDaddy can limit the amount of time that a process runs, so it is possible that the process took too long.
GoDaddy can also limit the amount of memory allowed to each process. Since the jobs worked on large arrays of data, it is possible that the length of time issue and the memory bloat issue could be solved by creating one job for each item instead of creating one job to iterate the array.
This is how I solved the problem. I did create a job that processed just one item. Instead of sending the whole array to one job, I iterated the array and sent each item to a job. I thought that this would increase the amount of time it took for the system to process each item, since the program has to bootstrap the application for each job as it loads, and now I have hundreds of jobs instead of one. However, if the total time increased, the time to process a single job would certainly decrease, because the job only processed a single item and then closed. Once I made this change, the GoDaddy server stopped throwing the NULL errors, and everything ran well.
I was also surprised to see that the smaller jobs also completed faster than the single job with the array. Even though the system had to bootstrap the application on each job, the system ran much faster when memory was not overloaded.

Yii2 - Migrating test database

I'm using codeception and I'm trying to run the migration for the test database.
From inside the tests folder I run the command
php codeception/bin/yii migrate/up --interactive=0
but I'm getting the error
Exception 'yii\base\InvalidConfigException' with message 'The configuration for the "user" component must contain a "class" element.'
in /www/shopboxyii-v2/vendor/yiisoft/yii2/di/ServiceLocator.php:205
Stack trace:
#0 /www/shopboxyii-v2/vendor/yiisoft/yii2/di/ServiceLocator.php(261): yii\di\ServiceLocator->set('user', Array)
#1 /www/shopboxyii-v2/vendor/yiisoft/yii2/base/Component.php(180): yii\di\ServiceLocator->setComponents(Array)
#2 /www/shopboxyii-v2/vendor/yiisoft/yii2/BaseYii.php(546): yii\base\Component->__set('components', Array)
#3 /www/shopboxyii-v2/vendor/yiisoft/yii2/base/BaseObject.php(107): yii\BaseYii::configure(Object(yii\console\Application), Array)
#4 /www/shopboxyii-v2/vendor/yiisoft/yii2/base/Application.php(206): yii\base\BaseObject->__construct(Array)
#5 /www/shopboxyii-v2/vendor/yiisoft/yii2/console/Application.php(89): yii\base\Application->__construct(Array)
#6 /www/shopboxyii-v2/tests/codeception/bin/yii(25): yii\console\Application->__construct(Array)
#7 {main}
Does anyone know anything about this error or what's causing it??
You don't need the user component configuration in the console/config/main.php (if using advanced-app) or app/config/web.php (if using basic-app), you should just remove the component configurations and it will start working seamlessly.

SIGSEGV - Crash on pthread_mutex_lock ()

i am currently executing a Pro*c code, where the pro*c shared library called from the parent program.
On certain scenario the shared library is crashing upon executing an embedded SQL statement.
I tried to debug the crash using the GDB command and found out it crashing when Pthread_mutex_lock() from /lib/libpthread.so.0.
I am not sure how to fix or the solution any help will be much appreciated.
Below is the error
7124 in imo4020.c
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0xf629a31d in pthread_mutex_lock () from /lib/libpthread.so.0
(gdb)
EXEC SQL
SELECT COUNT(*)
INTO :WSS_COUNT
FROM <Table_Name>
WHERE <Column1> = :<Column1_HostVariable> AND
<Column2> = :<Column2_HostVariable> AND
<Column3> = :<Column3_HostVariable> AND
<Column4> = :<Column4_HostVariable> AND
<Column5> = :<Column5_HostVariable>;

How to terminate an single gulp.watch change event listener while keeping the gulp script running

How to terminate an gulp.watch change event listener without terminating the rest of the gulp script?
Not an very elegant test case:
function paths() {
var paths = JSON.parse(fs.readFileSync('../../z/paths.json'))
gulp.watch(paths.scriptsFiles, ['test'])
return paths
}
gulp.task('test', () =>
gulp.src(paths().scriptsFiles)
.pipe(...)
.pipe(...)
)
Which leads to this error:
MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 change listeners added. Use emitter.setMaxListeners() to increase limit
I stumbled upon chokidar which says to be the underlying package in gulp. It is also very well documented with code examples.

GC Operation on unregistered thread

I am getting the following error on OS X Lion 10.7 in my application. I have pinpointed what is causing the error, but want to find out if this is a bug in 10.7 or if something has changed that I am missing.
malloc: *** auto malloc[3677]: error: GC operation on unregistered thread. Thread registered implicitly. Break on auto_zone_thread_registration_error() to debug.
The stack trace from GDB when running bt on the breakpoint:
#0 0x00007fff90742b44 in auto_zone_thread_registration_error ()
#1 0x00007fff9073a9a4 in auto_zone_allocate_object ()
#2 0x00007fff8f36335e in _Block_copy_internal ()
#3 0x00007fff8a9d7e9d in HALC_ProxyIOContext::StopIOProc ()
#4 0x00007fff8a9d7dc6 in __HAL_HardwarePlugIn_DeviceStop_block_invoke_30 ()
#5 0x00007fff8a9b8521 in HALB_Executor::DoIt ()
#6 0x00007fff8a9b84ce in HALB_Executor::Run ()
#7 0x00007fff8a9d7ce9 in HAL_HardwarePlugIn_DeviceStop ()
#8 0x00007fff8a9d7c6d in HALPlugIn::DeviceStopIOProc ()
#9 0x00007fff8a9d7bb1 in AudioDeviceStop ()
#10 0x00000001044b381c in AUHAL::StopHardware ()
#11 0x00000001044b397e in AUHAL::AUIOProc ()
#12 0x00007fff8a9d5362 in HALC_ProxyIOContext::IOWorkLoop ()
#13 0x00007fff8a9d4ac9 in HALC_ProxyIOContext::IOThreadEntry ()
#14 0x00007fff8a9d4984 in HALB_IOThread::Entry ()
#15 0x00007fff8fb2f8bf in _pthread_start ()
#16 0x00007fff8fb32b75 in thread_start ()`
The code that is causing this Garbage Collection thread error is:
NSSound *completedSound = [NSSound soundNamed:#"Glass"];
[completedSound play] //this line is causing the error;
All that line does is play one of the system sounds that are registered on the system as selected by the user. To me it seems like a bug, and I have filed a bug report just in case.
Anybody else experienced this?
Yes, indeed I have. The stack trace seems pretty similar as well. It seems to happen when a sound file stops playing, and I am pretty sure that it wasn't happening under 10.6. It doesn't seem to affect the actual running of my app, though.
There are also other cases of this error (with WebKit, mostly) that showed up on google while I was looking for the cause, and they all suggested that it wasn't really any sort of problem.
What was the bug report number?
Check to see if you have any third-party audio plugins installed, and remove them one by one. The crash report will show all loaded bundles.
I see the same message with the speech synthesizer stopping.