[INSERT] kills Seamonkey when posting to forum <KLUDGED>

[Sit Heel Speak]

Not the solution, but perhaps a clue which will contribute to finding it:

As otropogo reports: in 4.1-alpha-6, booted from an ATA disk, frugal install...hitting the Insert key in a Seamonkey reply window on this forum, makes Seamonkey vanish. Every. Single. Time.

However: the 4.1-alpha-6 SCSI-1 kernel, booted from an SCSI disk, frugal install, on the same machine...is bulletproof. I can hit the Insert key at will, til my finger gets sore, no problem.

My thinking now is, there is a conflict between the ATA / IDE driver and...the keyboard driver?

Perhaps a buffer "fencepost error" in the way Seamonkey handles the Insert key?

Later today I'll try booting the 4.1-alpha-6 SCSI-1 kernel, frugal, from an ATA disk and see what happens.

[Sit Heel Speak]

Hmm. Curious and curious-er.

Substituting the SCSI-1 kernel for the regular one, when booted from an ATA disk, frugal, does not cure the Insert key problem.

The SCSI-1 kernel only solves the Insert key problem when booted from an SCSI disk, doesn't matter whether frugal or full install.

There is a separate problem, when autoscroll is enabled, that very often middle-mousebutton-click-on-tab to delete the tab causes Seamonkey to vanish, just like the Insert key problem. Using the SCSI-1 kernel on an ATA frugal Puppy 4.1-alpha-6 does indeed banish this autoscroll-tabclick problem. But not the Insert-key-in-forum-reply-window gremlin.

[Flash]

Well that is curious. After my (PATA) HD died yesterday I took it out. Puppy showed about 70 MB of memory "free" and SeaMonkey shut down several times while it was just sitting there doing nothing. It never did that before the HD quit and took 500 MB of swap memory with it.

This morning I added another 256 MB stick of RAM, for a total of 512 MB. Now Puppy shows over 200 MB of memory "free," and SeaMonkey has not shut down all day. It would appear that Puppy needs more than 256 MB of RAM to run SeaMonkey without a hard disk drive.

Otropogo, you were right; SeaMonkey shuts down every time I hit the Insert key, as long as the focus is in the forum's compose window. I tried every key on my keyboard. The only one that causes SeaMonkey to shut down is the Insert key.

[Sit Heel Speak]

Perhaps I should here note, that my test machine has 2 GB of RAM. Freememapplet shows a minimum of 400 MB free, when booted frugal from SCSI, and 931 MB free when booted frugal from ATA.. Either installation is using a 512 MB swap partition as well.

My point is: lack of memory and/or disk space is not an issue with the Insert key Seamonkey vanishment problem, here.

[Sit Heel Speak]

Would everyone who is experiencing this problem do me a favor: power off, unplug the secondary IDE cable from your mainboard, and reboot.

Does the Insert key Seamonkey vanishment problem, still exist?

[Flash]

The insert key causes SeaMonkey to close, but only in the Puppy forum compose window. In addition, SeaMonkey sometimes spontaneously closes if I'm running with only one 256 MB stick of RAM. Whether the two are related I have no idea. It seems reasonable to me to suppose they might be, so I include them both.

Can anyone recommend another phpBB forum I could join, to see if the Insert key closes SeaMonkey there?

[otropogo]

Would everyone who is experiencing this problem do me a favor: power off, unplug the secondary IDE cable from your mainboard, and reboot.

Does the Insert key Seamonkey vanishment problem, still exist?

After strenuous efforts and extreme danger to my hard drive and cables, due to the micromanaged cable routing and bay configuration of my Dell 4300 clamshell tower, I finally managed to disconnect the secondary ide cable from the Motherboard, plug the primary cable into the DVD drive, and boot Puppy 4.0 as requested.

And, I'm sorry to report, the answer is YES. Hitting Insert still closes Seamonkey instantly when in the forum's post window.

BTW - I also tested for this defect with my laptop, running Seamonkey 1.1.2 under Puppy 3.01 Retro, and in that configuration, hitting [INSERT] (or rather, [INS] does NOT close Seamonkey.

[Sit Heel Speak]

OK, thanks for the trial. I asked for it because I discovered that 4.1-alpha-6, scsi-1 kernel, booted frugal from an scsi disk...does have the problem, if I connect my DVD writer to the IDE secondary. Disconnect the secondary entirely, the problem goes away.

My homebuilt has a vintage-2003 Supermicro X5DPE-G2 mainboard. If memory serves, your Dell 4300 has an Intel mainboard of similar vintage. I wonder if your, my, and Flash's three mainboards have the same keyboard controller. Clearly this problem is not very widespread, otherwise the complaint volume would be louder.

Bedtime now; I'll check our keyboard controllers' identities tomorrow. Also will conduct experiments with other devices (e.g. disk drives) on the secondary channel.

[otropogo]

Have just tried Opera in Muppy-Live (using it now), and hitting [INSERT] while text is entered in this post window does only what's expected.

Zooming the display while in the forum works more nicely in Opera too. I find 150% zoom quite comfortable for both reading and entering posts on my 19" monitor.

[otropogo]

Have just tried the [INSERT] key in Seamonkey under Muppy 084 LiveCD, while entering text here. Although the look is different (no search option at the URL field, for instance), the version number is the same - 1.1.8, yet hitting the killer key does nothing.

So presumably the bug is in Puppy, not Seamonkey.

Haven't had any developer feedback on whether this bug has been carried on into 4.1 or 4.1 Retro.

Would be a shame to have to live with it until Puppy 4.2.

[GeoW]

Clearly this problem is not very widespread, otherwise the complaint volume would be louder.

Actually, I have had this problem for a long time. I thought it was a
Seamonkey problem so I didn't report it here. IIRC it also happens
in Google Docs.

Not being a touch typist, I just stopped using the insert key - not too
hard since I have to look at the keyboard anyway.

Haven't had any developer feedback on whether this bug has been carried on into 4.1 or 4.1 Retro.

Would be a shame to have to live with it until Puppy 4.2.

I generally use Puppy 406 conservative since it is the only version
that does a full poweroff on my desktop.

The insert key vaporizes Seamonkey, as it has on earlier pups.

I just tried opening a second instance of Seamonkey on the second
desktop - the insert key vaporized both.

In response to your question, I have just tested 408 retro and 408.
Both have the insert vaporization feature.

My computer:
Intel D850MV, P4 @1.5GHz, 256MB PC800 RDRAM, 16G HD /w 1 NTFS partition

In all cases the puppies are frugal installations in folders.

Every time this happens I get this line added to /tmp/xerrs.log

Code: Select all

From 406 conservative:
/usr/lib/seamonkey-1.1.11/run-mozilla.sh: line 131:  4073 Segmentation fault      "$prog" ${1+"$@"}

From 408 retro:
/usr/lib/seamonkey-1.1.11/run-mozilla.sh: line 131:  3615 Segmentation fault      "$prog" ${1+"$@"}

From 408:
/usr/lib/seamonkey-1.1.11/run-mozilla.sh: line 131:  4781 Segmentation fault      "$prog" ${1+"$@"}

I hope this helps - it is beyond me.

GeoW

[otropogo]

Clearly this problem is not very widespread, otherwise the complaint volume would be

Actually, I have had this problem for a long time. I thought it was a
Seamonkey problem so I didn't report it here. IIRC it also happens
in Google Docs.

Thanks for the feedback GeoW. Are there any other specifics to the circumstances?

I haven't used Seamonkey in Google Docs. But I recently found that on my Puppy 4.0 Kernel 2.6.21 there are two conditions that have to be met for [INSERT] to kill Seamonkey (and yes, it kills all running instances, IIRC):

1. there must be text in this forum's post window, AND

2. the cursor must be in the window too

In other words, if I merely hit the "quote" button, but don't move the cursor to the input window, [INSERT] doesn't kill Seamonkey.

In response to your question, I have just tested 408 retro and 408.
Both have the insert vaporization feature.

My computer:
Intel D850MV, P4 @1.5GHz, 256MB PC800 RDRAM, 16G HD /w 1 NTFS partition

In all cases the puppies are frugal installations in folders.

Every time this happens I get this line added to /tmp/xerrs.log

Code: Select all

From 406 conservative:
/usr/lib/seamonkey-1.1.11/run-mozilla.sh: line 131:  4073 Segmentation fault      "$prog" ${1+"$@"}

From 408 retro:
/usr/lib/seamonkey-1.1.11/run-mozilla.sh: line 131:  3615 Segmentation fault      "$prog" ${1+"$@"}

From 408:
/usr/lib/seamonkey-1.1.11/run-mozilla.sh: line 131:  4781 Segmentation fault      "$prog" ${1+"$@"}

I hope this helps - it is beyond me.

GeoW

Beyond my skills also. And I'm using Seamonkey 1.1.8 in Muppy right now, where this Bug is not manifest. But will see whether I get similar results next time I run Puppy.

My Puppy 4.0 BTW is running strictly from RAM, loaded from the LiveCD each time I boot, and using a 2fs file on a Vfat partition.

[otropogo]

...
The insert key vaporizes Seamonkey, as it has on earlier pups.

...
In response to your question, I have just tested 408 retro and 408.
Both have the insert vaporization feature.

....

Every time this happens I get this line added to /tmp/xerrs.log

Code: Select all

From 406 conservative:
/usr/lib/seamonkey-1.1.11/run-mozilla.sh: line 131:  4073 Segmentation fault      "$prog" ${1+"$@"}

From 408 retro:
/usr/lib/seamonkey-1.1.11/run-mozilla.sh: line 131:  3615 Segmentation fault      "$prog" ${1+"$@"}

From 408:
/usr/lib/seamonkey-1.1.11/run-mozilla.sh: line 131:  4781 Segmentation fault      "$prog" ${1+"$@"}

I hope this helps - it is beyond me.

GeoW

Have just tried this with Puppy 4.0 K2.6.21 on my system: a Dell Dimension 4300 (Dumpster Special) with a 1.6GHz PIII (?) and half a GB of PC133 RAM

I opened the /tmp/xerrs.log, saved the contents elsewhere in Geany, deleted all the text in the original, saved, and then hit the Insert key..

When I reopened /tmp/xerrs.log it was still completely empty...

One other thing. It occurred to me that the INSERT bug might not be occurring in Muppy because of the choice of windows managers, and I couldn't be sure I'd actually tried it in JWM, as I would in Puppy.

So I switched to JWM, and tried it.

NOPE. INSERT doesn't kill Seamonkey in the JWM Desktop either under Muppy. So far it seems to be strictly a Puppy BUG ....

[thekevinday]

Have just tried this with Puppy 4.0 K2.6.21 on my system: a Dell Dimension 4300 (Dumpster Special) with a 1.6GHz PIII (?) and half a GB of PC133 RAM

I opened the /tmp/xerrs.log, saved the contents elsewhere in Geany, deleted all the text in the original, saved, and then hit the Insert key..

When I reopened /tmp/xerrs.log it was still completely empty...

One other thing. It occurred to me that the INSERT bug might not be occurring in Muppy because of the choice of windows managers, and I couldn't be sure I'd actually tried it in JWM, as I would in Puppy.

So I switched to JWM, and tried it.

NOPE. INSERT doesn't kill Seamonkey in the JWM Desktop either under Muppy. So far it seems to be strictly a Puppy BUG ....

I am someone who was looking into this problem myself.
I don't use puppy linux and I do get this problem.

I have seen this problem for some years now.
I was assuming it had something to do with my Custom-Compiled LFS system, being custom compiled and all...

As I was looking into the problem I came across this forum & thread where you have the same exact problem and came to the same results.

Apparently, clicking insert while the cursor is positioned inside any textbox will cause the crash consistently.

My system can run as live-cd & live-usb and generates the problem on any pc-hardware so hardware is not the problem.

I am using XFCE 4.4.2 as my windowmanager.
I am uClibc (0.9.28.3) based.
I am using gtk+ 2.12.11
I am using glib 2.16.5



The crash is a segfault that generates a coredump

I ran seamonkey against valgrind and got the following issue when I clicked the [insert] key:

Code: Select all

==14232== Invalid read of size 4
==14232==    at 0x44C108E: get_btree (in /lib/libgtk-x11-2.0.so.0.1200.11)
==14232==    by 0x44C1AC9: gtk_text_buffer_get_insert (in /lib/libgtk-x11-2.0.so
.0.1200.11)
==14232==    by 0x44DAD6A: text_window_invalidate_cursors (in /lib/libgtk-x11-2.
0.so.0.1200.11)
==14232==    by 0x44DD281: gtk_text_view_toggle_overwrite (in /lib/libgtk-x11-2.
0.so.0.1200.11)
==14232==    by 0x474C05C: g_cclosure_marshal_VOID__VOID (in /lib/libgobject-2.0
.so.0.1600.5)
==14232==    by 0x47412A8: g_type_class_meta_marshal (in /lib/libgobject-2.0.so.
0.1600.5)
==14232==    by 0x474272A: g_closure_invoke (in /lib/libgobject-2.0.so.0.1600.5)
==14232==    by 0x474F256: signal_emit_unlocked_R (in /lib/libgobject-2.0.so.0.1
600.5)
==14232==    by 0x47501D9: g_signal_emitv (in /lib/libgobject-2.0.so.0.1600.5)
==14232==    by 0x437CDD2: gtk_binding_entry_activate (in /lib/libgtk-x11-2.0.so
.0.1200.11)
==14232==    by 0x437D18B: binding_match_activate (in /lib/libgtk-x11-2.0.so.0.1
200.11)
==14232==    by 0x437D3D2: gtk_bindings_activate_list (in /lib/libgtk-x11-2.0.so
.0.1200.11)
==14232==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
==14271== 
==14271== ERROR SUMMARY: 115 errors from 8 contexts (suppressed: 0 from 0)
==14271== malloc/free: in use at exit: 13,223,782 bytes in 285,404 blocks.
==14271== malloc/free: 1,674,421 allocs, 1,389,017 frees, 285,942,862 bytes allo
cated.
==14271== For counts of detected errors, rerun with: -v
==14271== searching for pointers to 285,404 not-freed blocks.
==14271== checked 23,906,564 bytes.
==14271== 
==14271== LEAK SUMMARY:
==14271==    definitely lost: 413,301 bytes in 14,619 blocks.
==14271==      possibly lost: 667,170 bytes in 7,540 blocks.
==14271==    still reachable: 12,143,311 bytes in 263,245 blocks.
==14271==         suppressed: 0 bytes in 0 blocks.
==14271== Rerun with --leak-check=full to see details of leaked memory.

Ignoring how much memory seamonkey leaks, it looks like this might be a gtk+ or glib problem.

[Pizzasgood]

I'm getting this problem with Firefox 3.0.3 in Puppy 4.1. I got it officially, but I did manually replace some files in the profile folder to transfer in some bookmarks from another install.

I will have to investigate further later. Try it in a pristine copy, at different locations, and different versions of Puppy. See what's shaking.

[Pizzasgood]

Okay, my findings show that versions 1-3 of Firefox all crash on insert in a <textarea> widget, in Puppy 4.00 and 4.1. So does Seamonkey.

Seamonkey doesn't give me anything helpful. However, Firefox gives me this:

Code: Select all

bash-3.00# firefox WebPage.html 
/usr/local/firefox/crashreporter: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory

I don't know if that error is the one causing the crash, or if it happens after the crash when trying to load the crash reporter. I think the latter, because I never actually see this crash reporter in Firefox 3, which is the only version giving me that information. The other versions and seamonkey give me

Code: Select all

bash-3.00# seamonkey file:///tmp/dfd/WebPage.html 
/usr/lib/seamonkey-1.1.11/run-mozilla.sh: line 131:  1892 Segmentation fault      "$prog" ${1+"$@"}

Which basically means the error is comming from the seamonkey binary. Not necessarily where the error is, it's just the part that the error causes to break.


I had no issues in Puppy 3.01.

[disciple]

EDIT - oops

So, where we're at (still ):
In Puppy 4.x, and also thekevinday's linux system, Firefox/Seamonkey crash when the cursor is in a text entry box and the insert key is pressed.

I can't see anything about it in the Firefox bug reporting system - should we report it there?

[alienjeff]

I can't see anything about it in the Firefox bug reporting system - should we report it there?

NO! Do NOT report the bug. Instead patiently wait and see if it fixes itself ...

... ffs

[ttuuxxx]

EDIT - oops

So, where we're at (still ):
In Puppy 4.x, and also thekevinday's linux system, Firefox/Seamonkey crash when the cursor is in a text entry box and the insert key is pressed.

I can't see anything about it in the Firefox bug reporting system - should we report it there?

I tried it only in Seamonkey, and it killed Seamonkey & FirePup that I had both open at the same time, strange
ttuuxxx

[disciple]

NO! Do NOT report the bug. Instead patiently wait and see if it fixes itself ...

AJ, I only asked because of the suggestions it may be a GTK bug or something.