SIGILL on openVZ
I have a small openVZ slice I use for testing and personal projects.
Recently, the provider transferred to the new Xeon "Sandy Bridge"
platform; I am not sure if this is the cause of my problem or not, but
since then, I have been unable to use most of my mod_perl based
modules with apache. The apache worker receives SIGILL (Illegal
instruction) as soon as the module is called upon.
I've run httpd -X in gdb and posted an example backtrace here:
http://pastebin.com/16SrEzHM
The offending instruction is "dl_x86_64_save_sse" (I don't know any
assembly), and it is always from
/usr/src/debug/glibc-2.12.2/sysdeps/x86_64/dl-trampoline.S,
so perhaps not a strictly mod_perl issue, but I do not have the problem
with anything else. Context #5 in the backtrace relates to
Apache2::Const, and in fact a module like this:
use Apache2::Const qw(SERVER_ERROR);
sub handler {
return SERVER_ERROR;
}
Triggers the issue. Removing Apache2::Const and returning 500 does not.
Apache2::RequestRec is okay, but most other modules are not (and not
necessarily all Apache2 modules, eg, Mouse will also trigger this),
meaning most of my stuff is now non-functional. Regular perl scripts
using these modules are fine. I have tried recompiling them on "the
new platform" via CPAN; this did not make any difference.
I've been writing and using Apache/mod_perl modules for a few years and
this would be a very serious problem for me if it happened anywhere
else. I'm looking for some help in determining why this suddenly
happened and what I can do about it.
Thanks -- MK
--
"Enthusiasm is not the enemy of the intellect." (said of Irving Howe)
"The angel of history[...]is turned toward the past." (Walter Benjamin)
Re: SIGILL on openVZ
On Sun, 10 Jul 2011 08:07:05 -0400 Rick Myers wrote: > On Sat, Jul 09, 2011 at 09:05:28AM -0400, MK wrote: > > http://pastebin.com/16SrEzHM > > > > The offending instruction is "dl_x86_64_save_sse" (I don't know any > > assembly), and it is always from > > /usr/src/debug/glibc-2.12.2/sysdeps/x86_64/dl-trampoline.S, > > It appears to be an old glibc problem. Compare your trace with > > http://sourceware.org/bugzilla/show_bug.cgi?format=multiple&id=12113 Yeah. The "small reproducer" attached to that report does reproduce the problem on the system, which is also Fedora 13 running glibc 2.12. I'll have to ask the provider if they can make an upgrade available. Thanks! -- "Enthusiasm is not the enemy of the intellect." (said of Irving Howe) "The angel of history[...]is turned toward the past." (Walter Benjamin)
linux glibc and new "Sandy Bridge" AVX processors
After digging further into my problem with the SIGILL on an openVZ slice -- thanks much Rick Myers for the tip -- I'm trying to find out who, if anyone, is running mod_perl on an AVX enabled hardware. According to wikipedia, the only currently available processor using these extensions is the new Xeon Sandy Bridge. The VPS tech people provided me with a fresh fedora 14 slice using glibc 2.13 for testing, and the problem persists. I don't know how much software this affects -- the only thing I've noticed is mod_perl when using certain modules, such as Apache2::Const or Mouse, and a threaded httpd -- but if it is this underlying glibc issue then anyone else doing the same thing should be having the same problem. Thanks, MK -- "Enthusiasm is not the enemy of the intellect." (said of Irving Howe) "The angel of history[...]is turned toward the past." (Walter Benjamin)
Re: Changing browser URL based on condition
On Mon, 11 Jul 2011 11:48:09 -0700 Jerry Pereira wrote: > 1. User types the URL - www.example.com, this will display the login > page. > 2. Once the user enters the credentials and hits submit, the request > is posted to www.example.com/login action. > 3. If the credentials entered by the user is valid then i would like > to show the home page..uri > 4. I am able to show the homw page, but the URL does not change to > www.example.com/home, instead it remains the same (i.e. > www.example.com/login). One important reason to do something like that is because you do not want the user to bookmark or otherwise pass on an url with completely ambiguous content -- /login should refer to the login page, /home should refer to the home page, they are two different things. Having /login refer to both is no good. So I think your desire is justified. IMO, this is best handled client-side: you return your login data via an AJAX call. If the login succeeds, the client loads /home. If the login has failed, the client displays a message to that effect. You need to prevent spoofed access to /home, but of course you have to do that anyway (via cookies or whatever method you are already using). -- "Enthusiasm is not the enemy of the intellect." (said of Irving Howe) "The angel of history[...]is turned toward the past." (Walter Benjamin)
