Good feedback. I haven't done a memory check on that machine in a while....
Next on my list. On Sun, Dec 4, 2016 at 11:25 AM, Keith Medcalf <kmedc...@dessus.com> wrote: > > If pressing the CAPS LOCK or NUM LOCK keys on the keyboard does not toggle > the light on the keyboard then you have lost the all interrupt processing > since those keypresses have to be processed by the kernel mode keyboard > driver toggling the internal state of the keyboard driver, and then the > kernel driver sends output to the keyboard to change the status LEDs. > Typically (all Operating Systems) this means you have suffered a complete > kernel crash (or halt) and the system is not running. > > Since the system must be running in order to output indicator status, all > indicators will stay "stuck" in their last known position (hold output). > > Only a power-cycle (or hardware reset -- assuming the RESET is a hardware > reset and not just a request to reset which will be ignored) triggering a > reboot will restart the system. > > The most frequent cause is a Parity Check. Or in these latter days of not > having ECC or even Parity checked memory, just an undetected memory fault > which will cause random AHTBL. > > > -----Original Message----- > > From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] > > On Behalf Of Kevin O'Gorman > > Sent: Sunday, 4 December, 2016 09:21 > > To: SQLite mailing list > > Subject: Re: [sqlite] I keep getting seg faults building my database > using > > python sqlite3 > > > > Well, the i7 system failed again, but this time it was quite different. > > And peculiar. > > The system wasn't doing anything, but it should have been. So I tried > > something. It didn't matter what, because I could not get the mouse or > > keyboard to work -- it was like they weren't plugged in. Really like it, > > because the caps lock light wasn't on, nor was the laser light visible in > > the mouse. Even when I changed mouse, keyboard and USB slot. I couldn't > > get in with SSH from elsewhere either. But the computer's "I'm running" > > light was on. > > So I'm suspecting a partial power failure. I don't know enough about > > mobos > > and USB to diagnose whether the problem was on the mobo or the power > > supply. > > > > Creepty. I had to do a hard reset to get thing going again, and it's > > been > > running fine for a day now. > > > > On Mon, Nov 21, 2016 at 9:51 AM, Kevin O'Gorman <kevinogorm...@gmail.com > > > > wrote: > > > > > On Mon, Nov 21, 2016 at 9:41 AM, Roger Binns <rog...@rogerbinns.com> > > > wrote: > > > > > >> On 19/11/16 08:08, Kevin O'Gorman wrote: > > >> > System with problems: Running Xubuntu Linux 16.04.1, Python 3.5.2. > > >> [...] > > >> > System without this problem: Running Ubuntu Linux 14.04.5, Python > > 3.4.3. > > >> > > >> You are good on Python versions then. My remaining recommendation is > > to > > >> make the process that does SQLite be a child process (ie no making its > > >> own children). That will eliminate an entire class of potential > > >> problems, although it appears unlikely you are experiencing any of > > them. > > >> > > >> The final option is to run the process under valgrind. That will > > >> definitively show the cause. Do note however that you may want to > > >> change some of the default options since you have nice big systems. > > For > > >> example I like to set --freelist-vol and related to very big numbers > > >> (several gigabytes) which ensures that freed memory is not reused for > a > > >> long time. You could also set the valgrind option so that only one > > >> thread is allowed - it will catch inadvertent threading you may note > be > > >> aware of. > > >> > > >> Roger > > >> > > > > > > Thanks for that. I may do the valgrind thing -- it sounds useful. But > > > just to add > > > to my annoyance about this whole things, I've been having both systems > > > running > > > for a couple of days now with no problems or interruptions. Remember, > > the > > > i7 system was failing after 2 hours at most. I did tweak the code a > > > little, but > > > the only thing that seems likely to have stopped the problem is that I > > put > > > in > > > code to do a commit after every 10,000 INSERT statements. The two > > systems > > > are running identical Python code on the same inputs. I had intended > > this > > > to > > > verify that one fails and the other does not. What I got is something > > > different, > > > but on balance I like it best when my processes do not fail out. Maybe > > > this > > > time the code will finish (at this rate it will be at least a week, > > maybe > > > three. > > > > > > -- > > > #define QUESTION ((bb) || (!bb)) /* Shakespeare */ > > > > > > > > > > > -- > > #define QUESTION ((bb) || (!bb)) /* Shakespeare */ > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- #define QUESTION ((bb) || (!bb)) /* Shakespeare */ _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
