On 16 October 2011 22:33, pbzRPA <[email protected]> wrote: > Hi Graham, > > I did read further but I am not a linux guru and the instructions > simple are not detailed enough to know what should be done :( > > In the instructions it says: > > $ sudo gdb /usr/local/apache/bin/httpd 666
You should be able to do: sudo gdb -p 666 as well, where '666' is replaced with actual process ID. I used the prior form as older gdb versions don't from memory accept the latter way. The path '/usr/local/apache/bin/httpd' just had to be replace with the actual path of your Apache executable. > I do not have a "/usr/local/apache/bin/httpd" path or command. I have > no idea what I should replace this with . I have already changed my > apache to run in single daemon mode and I get the PID > > 11:24:51|/etc/apache2/sites-available$ ps aux | grep "ETServer" > etalent 5676 0.0 0.8 12620 4564 ? Sl 11:17 0:00 > ETServer -k start > > When I try to use this in gdb: > > karol@vz4703|11:24:11|~$ sudo gdb > GNU gdb (GDB) 7.0.1-debian > Copyright (C) 2009 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/ > gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "i486-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > (gdb) attach 5676 > Attaching to process 5676 > warning: The current binary is a PIE (Position Independent > Executable), which > GDB does NOT currently support. Most debugger features will fail if > used > in this session. If your gdb can't handle connecting to the process then there is something very wrong with your gdb or the way your Apache is compiled is very weird. Not sure I can help you if that doesn't work. > So I don't know what to do further. Verify you are actually running in the main interpreter. See: http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Sub_Interpreter_Being_Used Does the crash happen on the very first request which hits the application or at some random time later. Another option is that the pango code is not thread safe. Try ensuring stuff is in a single threaded process by specifying threads=1 to WSGIDaemonProcess. Also make sure you aren't mixing Python binaries/installations from different versions and make sure mod_python not loaded into same Apache. Go through some of the checks in: http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Shared_Library to make sure mod_wsgi is using Python version you expect and not different to any Python virtual environment you might be using. Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
