Not incredibly familiar with KDE but no fear of the command line.  Tell me what to provide and I think I can provide a useful information set.

unfortunately the backtrace is missing. Please add the backtrace provided by DrKonqui. It might be required to deactivate apport to get DrKonqui handling the crashes. In any case you need the package kdebase-workspace-dbg to get useful backtraces. Thanks.

sounds more like an X11 segfault to me "and user is faced with login prompt from which a new session is started and the kdm login prompt quickly appears"

@duane:
that means "you see VT1 (text shell terminal) and then KDM"?
in case: ctrl+alt+f1, ps -Af | grep X (to get the x11 pid), gbd 2>&1 | tee ~/gdb.x11.session, attach <x11 pid>, continue, ctrl+alt+f7

trigger crash, kdm should not automatically re-appear but gdb catches the process, enter "bt" to get a backtrace (of X11)

if you launched gdb like mentioned above (gbd 2>&1 | tee ~/gdb.x11.session) you've all output (including the bt) stored in ~/gdb.x11.session (so don't kill a tree writing it down ;-)

this would however be an upstream bug (xorg.conf, maybe a driver) then (clients are not supposed to crash the X server - ever)

Two things:

Please note that this was also filed on Ubuntu Launchpad and has seen some
activity (Please see
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/551754).  No need
to duplicate efforts but I don't know how to link the teams other than
informing each of the other.  Based on that activity it would appear to have
been identified as an xorg-server issue.  Being an xorg-server issue and the
statement below that a client should not crash the server, I thought this a
fairly important bug to handle during the beta cycle, especially since
running noscript in firefox in (choose your operating system) is a fairly
common scenario.

Second note is that I have copied your advice to a text file and intend to
run a scenario when I get home from work (headed that way shortly).  And
don't worry about the killing of the trees -- I make notes but nothing that
long.  Not that I'm such the environmental steward -- more like I don't want
to wear out my hand.  (Both are good reasons to me ;-).

Cheers!

On Mon, Apr 12, 2010 at 3:56 AM, Thomas Lübking <thomas.luebking@web.de>wrote:

> https://bugs.kde.org/show_bug.cgi?id=233988
>
>
>
>
>
> --- Comment #3 from Thomas Lübking <thomas luebking web de>  2010-04-12
> 09:56:00 ---
> sounds more like an X11 segfault to me "and user is faced with login prompt
> from which a new session is started and the kdm login prompt quickly
> appears"
>
> @duane:
> that means "you see VT1 (text shell terminal) and then KDM"?
> in case: ctrl+alt+f1, ps -Af | grep X (to get the x11 pid), gbd 2>&1 | tee
> ~/gdb.x11.session, attach <x11 pid>, continue, ctrl+alt+f7
>
> trigger crash, kdm should not automatically re-appear but gdb catches the
> process, enter "bt" to get a backtrace (of X11)
>
> if you launched gdb like mentioned above (gbd 2>&1 | tee ~/gdb.x11.session)
> you've all output (including the bt) stored in ~/gdb.x11.session (so don't
> kill
> a tree writing it down ;-)
>
> this would however be an upstream bug (xorg.conf, maybe a driver) then
> (clients
> are not supposed to crash the X server - ever)
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
> You reported the bug.
>

hmmm, looks like an radeon/exa/kms issue, this link* has a patch reported to work
the initial launchpad report seems to refer to gnome, thus rather compiz or mutter than kwin.

the noscript dialog looks like a handcrafted popup with a special frame.
it's just a shot in the dark but you could try running firefox skipping ARGB support:
form konsole/xterm run

export XLIB_SKIP_ARGB_VISUALS=1
firefox


*https://bugs.freedesktop.org/show_bug.cgi?id=27510

Still no-go on two fronts.

I created a bash script with the two lines below:
export XLIB_SKIP_ARGB_VISUALS=1
firefox

While the script ran fine and firefox started with no apparent
difficulty, the problem still exists ... clicking the noscript icon
crashes the session.

The previous advice was also attempted, that is using gdb in a tty
session to trap the error.  Getting into the tty session was not a
problem.  Getting back to the kwin session was.  Once gdb seemed to
run well up to and including the 'continue' command but <Ctrl+Alt+F7>
(or F8...) did not take me back to the X session.  Furthermore, the
system became unresponsive.  I could not seem to get out of the gdb
session normally but had to run <Alt+SysRq + R/S/E/I/U/B> at least up
to 'E' to crash the X session and get a useful login prompt since
<Ctrl+Alt+F?> would not allow me to jump into any tty session.  The
system was essentially frozen until using the SysRq commands.

I agree that at least the main issue is upstream of Firefox and may be
upstream of KDE as has previously suggested (say, xorg-server or the
like).  However, a secondary issue may exist in the coding for Firefox
and/or NoScript.

I've seen a few updates come down the pike that has upgraded Xorg
files but as of these latest updates the problem still exists.  What I
do not know is that if this is an issue with the Kubuntu beta or if
this is an issue that has just surfaced because of the beta.  In other
words, did the vulnerability exist at the server level but there was,
up until now, nothing that would exploit that vulnerability?  Or is
the vulnerability a result of modifications by the Kubuntu (or Ubuntu)
beta team(s)?

On Tue, Apr 13, 2010 at 9:44 AM, Thomas Lübking <thomas.luebking@web.de> wrote:
>
> https://bugs.kde.org/show_bug.cgi?id=233988
>
>
> Thomas Lübking <thomas.luebking@web.de> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Status|NEEDSINFO                   |RESOLVED
>         Resolution|BACKTRACE                   |UPSTREAM
>
>
>
>
> --- Comment #5 from Thomas Lübking <thomas luebking web de>  2010-04-13 15:44:31 ---
> hmmm, looks like an radeon/exa/kms issue, this link* has a patch reported to
> work
> the initial launchpad report seems to refer to gnome, thus rather compiz or
> mutter than kwin.
>
> the noscript dialog looks like a handcrafted popup with a special frame.
> it's just a shot in the dark but you could try running firefox skipping ARGB
> support:
> form konsole/xterm run
>
> export XLIB_SKIP_ARGB_VISUALS=1
> firefox
>
>
> *https://bugs.freedesktop.org/show_bug.cgi?id=27510
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
> You reported the bug.

Do I read this correctly that the bug has been resolved upstream?  If
so, what do I do to resolve the issue on my system?  My apologies if
I'm being dense here.  ;-)

Cheers!

On Tue, Apr 13, 2010 at 9:44 AM, Thomas Lübking <thomas.luebking@web.de> wrote:
> https://bugs.kde.org/show_bug.cgi?id=233988
>
>
> Thomas Lübking <thomas.luebking@web.de> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Status|NEEDSINFO                   |RESOLVED
>         Resolution|BACKTRACE                   |UPSTREAM

"resolved upstream" is the bugzilla way to say "someone elses problem" - that does not mean the bug is any fixed, just the kwin solution is to blame so. else :(

i did so as this is not a kwin (and probably KDE) bug at all.
the noscript plugin for firefox apparently triggers this regardless of the used WM (or even DE? - see the fdo bug - ubuntu defaults to gnome), but very related to the GPU/driver. 
(i cannot reproduce it on eg. nvidia)

please notice that this is no k/ubuntu bugtracker so the related questions cannot expected be answered here.
this is also not a firefox bugtracker, so "However, a secondary issue may exist in the coding for Firefox and/or NoScript." doesn't apply either

to get this fixed, the core bug seems to be in the radeon(hd?) driver but the fastest workaround might come from the noscript authors (by just using a std popup there, maybe ask about the specialities, i don't know a way to xprop a window)

_iff_ this is related to compositing, you'll unfortunately have to disable it or try the XRender backend (as for kwin)

ps: i am sorry for asking to gdb X11 - it indeed causes a hold here as well, no idea why though :-(

You've been more than kind.  I have confirmed that this is not unique to KDE but happens in Xfce as well.  Furthermore it is confirmed on two laptops, one with ATI Radeon M6 LY and the other with the nVidia card.  Also confirmed that it is not a profile issue nor is it solely NoScript but other Add-Ons (Cookie Monster is the latest) have demonstrated this issue.  This is an issue between firefox and xorg-server but so far only in the Ubuntu Lucid development branch.  "Resolved as Upstream" makes more sense than ever now.  ;-)

Take care,
Duane