Opened 7 years ago

Last modified 6 years ago

#886 reopened defect

Crash on locked database

Reported by: Sewi Owned by: Sewi
Priority: critical Milestone:
Component: editor Version: trunk
Keywords: Cc:


Run the following command:

./ --die -- --actionqueue=file.quit & ./ --die -- --actionqueue=file.quit &

One of the tasks exits with

DIE: DBD::SQLite::db do failed: database is locked at (eval 144) line 36.

 at (eval 144) line 36
	Padre::DB::do('Padre::DB', 'delete from host_config') called at (eval 144) line 672
	Padre::DB::HostConfig::truncate('Padre::DB::HostConfig') called at /home/sewi/padre/Padre/lib/Padre/Config/ line 75
	Padre::Config::Host::write('Padre::Config::Host=HASH(0x8873748)') called at /home/sewi/padre/Padre/lib/Padre/ line 163
	Padre::Config::write('Padre::Config=ARRAY(0x87cd978)') called at /home/sewi/padre/Padre/lib/ line 253
	Padre::save_config('Padre=HASH(0x8681b00)') called at /home/sewi/padre/Padre/lib/Padre/Wx/ line 1967
	Padre::Wx::Main::show_syntax('Padre::Wx::Main=HASH(0x93f19e8)', 0) called at /home/sewi/padre/Padre/lib/Padre/Wx/ line 323
	Padre::Wx::Main::timer_start('Padre::Wx::Main=HASH(0x93f19e8)') called at /home/sewi/padre/Padre/lib/Padre/Wx/ line 248
	Padre::Wx::Main::__ANON__('Padre::Wx::Main=HASH(0x93f19e8)', 'Wx::TimerEvent=SCALAR(0x90062d0)') called at /home/sewi/padre/Padre/lib/ line 242
	eval {...} called at /home/sewi/padre/Padre/lib/ line 242
	Padre::run('Padre=HASH(0x8681b00)') called at /home/sewi/padre/Padre/script/padre line 151

DIE: DBD::SQLite::db do failed: database is locked at (eval 144) line 36.

 at /home/sewi/padre/Padre/lib/ line 242
	Padre::run('Padre=HASH(0x8681b00)') called at /home/sewi/padre/Padre/script/padre line 151
DBD::SQLite::db do failed: database is locked at (eval 144) line 36.

(Happens on very most of the tries.)

Padre should wait a random amount of time if the database is locked and try again.

The problem also happens when exiting more than one Padre task at the same time (system shutdown, for example).

Change History (5)

comment:1 Changed 7 years ago by waxhead

  • Owner set to Sewi
  • Status changed from new to assigned


Can you confirm this is still the case?

If so, maybe send it Adam's way... ?

comment:2 Changed 6 years ago by claudio

  • Resolution set to fixed
  • Status changed from assigned to closed

The problem seems not to exist any longer (ticket is 12month old). Sewi, please reopen the ticket if you have the issue.

comment:3 Changed 6 years ago by Sewi

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version changed from 0.58 to trunk

The problem still exists. The ticket wasn't updated because nothing new happend.

Your computer might be too fast for the simple sample, but you could open or close two big sessions at the same time (in different instances) - and Padre will crash.

We could reduce database locking times, but we'll only reduce the number of times this happens - much better would be a clean error handling and retry if the first access failed.

comment:4 Changed 6 years ago by szabgab

This sounds like something you could reproduce even without the gui. Then it might be relatively easy to write tests for it. Then a fix would be more permanent.

comment:5 Changed 6 years ago by Sewi

All Padre DB access is done directly through ORLite. There is no "one place" where we could add a retry.

Things seem to be better because I need to run Padre three times (adding another instance to the sample) to get this error on every try.

Alias: What about adding a "retry" option to ORLite?

Note: See TracTickets for help on using tickets.