Re: [web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
I'd just rebuild the source RPM if I was you. Way simpler... besides you'll need to take care of the updates all by yourself now, same as for your postgres. Just taking Red Hat (or CentOS) updates and rebuilding them (couple of seconds of work) really simplifies things. Your postges RPMs are from the upstream, I guess? Regards, Ales On Wednesday, September 12, 2012 6:23:25 AM UTC+2, lucas wrote: ok, i am working on installing the psycopg2 from source, i got it to compile and it looked like it was installed under the python site_packages, but when i just try to import it into python i get import psycopg2 Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.6/site-packages/psycopg2-2.4.5-py2.6-linux-i686.egg/psycopg2/__init__.py, line 67, in module from psycopg2._psycopg import BINARY, NUMBER, STRING, DATETIME, ROWID ImportError: /usr/lib/python2.6/site-packages/psycopg2-2.4.5-py2.6-linux-i686.egg/psycopg2/_psycopg.so: undefined symbol: GSS_C_NT_HOSTBASED_SERVICE is there a good forum for psycopg2 anywhere? lucas --
Re: [web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
it took a while to figure this out, but with the postgres repository that i am using for 9.1, the python-psycopg2 rpm that is installed on my system is from the pgdg91 repository. so i would have to conclude that the psycopg2 driver from that repository is for postgresql-9.1 and not the centos 6.x/postgres-8.4. so hopefully that is sound logic now. --
Re: [web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
ok, maybe some progress. i removed any instances of psycopg2 from my computer and web2py by default was and is not forced to use only the contrib/pg8000 driver. i think i would rather use that one anyway. when i changed the pool_size from the default 0 to 16, the initial ticket/exception above stopped being logged. so i was under the impression that all was good again, but then my users have still been having logging in, but this time it tells them it is an unrecoverable error and when i try to see the ticket on their computer after this message, i can't pull anything up. so now i can not trace the problem and the users still have infrequent times the site is crashing unrecoverably. when i look into the ticket logs i only get a bunch of these: Traceback (most recent call last): File /opt/web-apps/web2py/gluon/restricted.py, line 209, in restricted exec ccode in environment File /opt/web-apps/web2py/applications/admin/controllers/default.py https://weinstruct.org/admin/default/edit/admin/controllers/default.py, line 1726, in module File /opt/web-apps/web2py/gluon/globals.py, line 185, in lambda self._caller = lambda f: f() File /opt/web-apps/web2py/applications/admin/controllers/default.py https://weinstruct.org/admin/default/edit/admin/controllers/default.py, line 1548, in ticket e.load(request, app, ticket) File /opt/web-apps/web2py/gluon/restricted.py, line 168, in load d = ticket_storage.load(request, app, ticket_id) File /opt/web-apps/web2py/gluon/restricted.py, line 96, in load return cPickle.load(ef) EOFError but i am not sure what this means because it looks internal to web2py. i have upgraded to 2.0.8 a few days ago; so i am up to date. so i am still having trouble finding if it is the postgresql-9.1, the pg8000 driver, web2py, the DAL, my code, my views, i just don't know. pretty frustrating. lucas --
Re: [web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
This traceback means the ticket file is corrupted/truncated. On Tuesday, 11 September 2012 06:18:11 UTC-5, lucas wrote: ok, maybe some progress. i removed any instances of psycopg2 from my computer and web2py by default was and is not forced to use only the contrib/pg8000 driver. i think i would rather use that one anyway. when i changed the pool_size from the default 0 to 16, the initial ticket/exception above stopped being logged. so i was under the impression that all was good again, but then my users have still been having logging in, but this time it tells them it is an unrecoverable error and when i try to see the ticket on their computer after this message, i can't pull anything up. so now i can not trace the problem and the users still have infrequent times the site is crashing unrecoverably. when i look into the ticket logs i only get a bunch of these: Traceback (most recent call last): File /opt/web-apps/web2py/gluon/restricted.py, line 209, in restricted exec ccode in environment File /opt/web-apps/web2py/applications/admin/controllers/default.py https://weinstruct.org/admin/default/edit/admin/controllers/default.py, line 1726, in module File /opt/web-apps/web2py/gluon/globals.py, line 185, in lambda self._caller = lambda f: f() File /opt/web-apps/web2py/applications/admin/controllers/default.py https://weinstruct.org/admin/default/edit/admin/controllers/default.py, line 1548, in ticket e.load(request, app, ticket) File /opt/web-apps/web2py/gluon/restricted.py, line 168, in load d = ticket_storage.load(request, app, ticket_id) File /opt/web-apps/web2py/gluon/restricted.py, line 96, in load return cPickle.load(ef) EOFError but i am not sure what this means because it looks internal to web2py. i have upgraded to 2.0.8 a few days ago; so i am up to date. so i am still having trouble finding if it is the postgresql-9.1, the pg8000 driver, web2py, the DAL, my code, my views, i just don't know. pretty frustrating. lucas --
Re: [web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
oh cr#p, because i was able to definitely trace that cPickle.load error to the unrecoverable error. makes sense now. so how can i narrow this terrible thing down. i am using apache httpd 2.2.15 on centos 6.3, postgresql 9.1 with the web2py contrib pg8000 driver, and web2py 2.0.8. i have excluded any unnecessary code as much as i could, pool_size=7 which changed from my first ticket to this unrecoverable, and i am not doing any hard commit() or rollback() and such. i do a few db.update, db.insert, but that is the most manual i get, and again the exceptions are always when a user is logging in. i have also noted that the server will kick off a user in mid session and the user has to re-login. so i am not sure it is with the connection to the db or the session controller. perhaps it is the way i have my /etc/httpd/conf.d/default.conf file configured for multiple domain names. can someone point me to some example entries for that file for multiple domains using web2py applications? but this has to be fixed, one way or the other because it is sucking wind like crazy and i have been chasing my tail for 3 weeks now. thanx for the help and i hope some solution avails itself to bring in stability. please. lucas --
Re: [web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
Some problems have been reported with pg8000. Can you reproduce the errors with psycopg2. Can you email me one of the corrupt tickets? I may be able to read them and see what is going on. On Tuesday, 11 September 2012 09:31:46 UTC-5, lucas wrote: oh cr#p, because i was able to definitely trace that cPickle.load error to the unrecoverable error. makes sense now. so how can i narrow this terrible thing down. i am using apache httpd 2.2.15 on centos 6.3, postgresql 9.1 with the web2py contrib pg8000 driver, and web2py 2.0.8. i have excluded any unnecessary code as much as i could, pool_size=7 which changed from my first ticket to this unrecoverable, and i am not doing any hard commit() or rollback() and such. i do a few db.update, db.insert, but that is the most manual i get, and again the exceptions are always when a user is logging in. i have also noted that the server will kick off a user in mid session and the user has to re-login. so i am not sure it is with the connection to the db or the session controller. perhaps it is the way i have my /etc/httpd/conf.d/default.conf file configured for multiple domain names. can someone point me to some example entries for that file for multiple domains using web2py applications? but this has to be fixed, one way or the other because it is sucking wind like crazy and i have been chasing my tail for 3 weeks now. thanx for the help and i hope some solution avails itself to bring in stability. please. lucas --
Re: [web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
On Tuesday, September 11, 2012 10:35:02 AM UTC-4, Massimo Di Pierro wrote: Some problems have been reported with pg8000. Can you reproduce the errors with psycopg2. yes, i can reinstall the psycopg2 rpm package. how do you specify and ensure that web2py is using that driver in the DAL? what is the syntax in the DAL statement and is there a db.driver property to see which one it is using? do you think i should use the psycopg2 rpm package or recompile it from source for postgresql 9.1? Can you email me one of the corrupt tickets? I may be able to read them and see what is going on. what is your email address? --
Re: [web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
print db._adapter.driver_name but psycopg2 always gets priority over pg8000 unless otherwise specified in driver_args. On Tuesday, 11 September 2012 11:11:43 UTC-5, lucas wrote: On Tuesday, September 11, 2012 10:35:02 AM UTC-4, Massimo Di Pierro wrote: Some problems have been reported with pg8000. Can you reproduce the errors with psycopg2. yes, i can reinstall the psycopg2 rpm package. how do you specify and ensure that web2py is using that driver in the DAL? what is the syntax in the DAL statement and is there a db.driver property to see which one it is using? do you think i should use the psycopg2 rpm package or recompile it from source for postgresql 9.1? Can you email me one of the corrupt tickets? I may be able to read them and see what is going on. what is your email address? --
Re: [web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
About python-psycopg2 - I'd rebuild the source rpm with your 9.1 posgresql-devel, just in case. RHEL/CentOS 6 originally ships with postgres 8.4.x, so this might be an issue. Usual caveats apply - don't (re)build rpm packages as root, etc. Regards, Ales On Tuesday, September 11, 2012 6:11:43 PM UTC+2, lucas wrote: On Tuesday, September 11, 2012 10:35:02 AM UTC-4, Massimo Di Pierro wrote: Some problems have been reported with pg8000. Can you reproduce the errors with psycopg2. yes, i can reinstall the psycopg2 rpm package. how do you specify and ensure that web2py is using that driver in the DAL? what is the syntax in the DAL statement and is there a db.driver property to see which one it is using? do you think i should use the psycopg2 rpm package or recompile it from source for postgresql 9.1? Can you email me one of the corrupt tickets? I may be able to read them and see what is going on. what is your email address? --
Re: [web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
ok, i am working on installing the psycopg2 from source, i got it to compile and it looked like it was installed under the python site_packages, but when i just try to import it into python i get import psycopg2 Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.6/site-packages/psycopg2-2.4.5-py2.6-linux-i686.egg/psycopg2/__init__.py, line 67, in module from psycopg2._psycopg import BINARY, NUMBER, STRING, DATETIME, ROWID ImportError: /usr/lib/python2.6/site-packages/psycopg2-2.4.5-py2.6-linux-i686.egg/psycopg2/_psycopg.so: undefined symbol: GSS_C_NT_HOSTBASED_SERVICE is there a good forum for psycopg2 anywhere? lucas --
Re: [web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
lucas, OK. So there is no error at SQL level. The problem is probably a closing cursor that happens somewhere in the DAL, that is triggered by some usage/environment peculiar to your application. Check the following just to be sure: 1) pooling connections. Try to work with pooled connection and without and see if anything changes. 2) explicit commits, rollbacks. 3) access to DBAPI cursor bypassing the DAL. 4) check if psycopg2 is recent and compiled againsts libpq-9.1 Also what kind of server configuration you have? rocket, apache+wsgi or ... Does the error happen on a multicore machine and there are concurrent requests? See the pooling item above.. What we really need is a simplified version of your code that shows the same error. mic 2012/9/7 lucas sjluk...@gmail.com ok, so i turned on debug5 in the postgres.conf file and restarted it. gives lots of entries. i then waited for that type ticket to arise again, it did, and traced to logs to that date/time stamp. the entries are below. i really can't see anything unusual except to say that it is occuring at login. i don't know exactly what kind of error postgres might give, but it looks like it commits and tidies up after the queries just fine. not really seeing any problem there and it only confirms that web2py is bugging during the login. lucas. 2012-09-06 19:51:07 EDT: [unknown]LOG: connection received: host=127.0.0.1 port=50185 2012-09-06 19:51:07 EDT: [unknown]DEBUG: postmaster child[27375]: starting with ( 2012-09-06 19:51:07 EDT: [unknown]DEBUG: postgres 2012-09-06 19:51:07 EDT: [unknown]DEBUG: weinstruct 2012-09-06 19:51:07 EDT: [unknown]DEBUG: ) 2012-09-06 19:51:07 EDT: [unknown]DEBUG: InitPostgres 2012-09-06 19:51:07 EDT: [unknown]DEBUG: my backend ID is 2 2012-09-06 19:51:07 EDT: [unknown]DEBUG: StartTransaction 2012-09-06 19:51:07 EDT: [unknown]DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2012-09-06 19:51:07 EDT: [unknown]DEBUG: received password packet 2012-09-06 19:51:07 EDT: [unknown]LOG: connection authorized: user=postgres database=weinstruct 2012-09-06 19:51:07 EDT: [unknown]DEBUG: CommitTransaction 2012-09-06 19:51:07 EDT: [unknown]DEBUG: name: unnamed; blockState: STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2012-09-06 19:51:07 EDT: [unknown]DEBUG: StartTransactionCommand 2012-09-06 19:51:07 EDT: [unknown]STATEMENT: BEGIN 2012-09-06 19:51:07 EDT: [unknown]DEBUG: StartTransaction 2012-09-06 19:51:07 EDT: [unknown]STATEMENT: BEGIN 2012-09-06 19:51:07 EDT: [unknown]DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2012-09-06 19:51:07 EDT: [unknown]STATEMENT: BEGIN 2012-09-06 19:51:07 EDT: [unknown]DEBUG: ProcessUtility 2012-09-06 19:51:07 EDT: [unknown]STATEMENT: BEGIN 2012-09-06 19:51:07 EDT: [unknown]DEBUG: CommitTransactionCommand 2012-09-06 19:51:07 EDT: [unknown]STATEMENT: BEGIN 2012-09-06 19:51:07 EDT: [unknown]DEBUG: StartTransactionCommand 2012-09-06 19:51:07 EDT: [unknown]STATEMENT: SET standard_conforming_strings=on; 2012-09-06 19:51:07 EDT: [unknown]DEBUG: ProcessUtility 2012-09-06 19:51:07 EDT: [unknown]STATEMENT: SET standard_conforming_strings=on; 2012-09-06 19:51:07 EDT: [unknown]DEBUG: CommitTransactionCommand 2012-09-06 19:51:07 EDT: [unknown]STATEMENT: SET standard_conforming_strings=on; 2012-09-06 19:51:08 EDT: [unknown]DEBUG: StartTransactionCommand 2012-09-06 19:51:08 EDT: [unknown]STATEMENT: SELECT auth_user.id, auth_user.prefix_title, auth_user.first_name, auth_user.last_name, auth_user.nick_name, auth_user.city_state, auth_user.zip, auth_user.gender, auth_user.age, auth_user.birthdate, auth_user.name_of_college_or_university, auth_user.school_id, auth_user.degree_seeking, auth_user.email, auth_user.password, auth_user.registration_key, auth_user.reset_password_key, auth_user.registration_id, auth_user.professor, auth_user.create_lecture_request, auth_user.create_lecture_agreement, auth_user.create_lecture_foldername, auth_user.input_date FROM auth_user WHERE (auth_user.email = 'dykab...@yahoo.com'); 2012-09-06 19:51:08 EDT: [unknown]DEBUG: CommitTransactionCommand 2012-09-06 19:51:08 EDT: [unknown]STATEMENT: SELECT auth_user.id, auth_user.prefix_title, auth_user.first_name, auth_user.last_name, auth_user.nick_name, auth_user.city_state, auth_user.zip, auth_user.gender, auth_user.age, auth_user.birthdate, auth_user.name_of_college_or_university, auth_user.school_id, auth_user.degree_seeking, auth_user.email, auth_user.password, auth_user.registration_key, auth_user.reset_password_key, auth_user.registration_id, auth_user.professor, auth_user.create_lecture_request, auth_user.create_lecture_agreement, auth_user.create_lecture_foldername, auth_user.input_date FROM auth_user WHERE (auth_user.email = 'dykab...@yahoo.com'); 2012-09-06 19:51:08 EDT:
Re: [web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
On Friday, September 7, 2012 4:57:37 AM UTC-4, Michele Comitini wrote: lucas, OK. So there is no error at SQL level. The problem is probably a closing cursor that happens somewhere in the DAL, that is triggered by some usage/environment peculiar to your application. Check the following just to be sure: 1) pooling connections. Try to work with pooled connection and without and see if anything changes. educate me a bit, how do i turn on/off pooling connections? this is what i know for sure. once a user gets the internal error/ticket with db cursor has been closed, the only way to get that user logged in, is by having them clear all cookies and website data in their browser, and i clearing all sessions under the application's sessions folder, and then restarting the httpd service. then the user can login, but also what is unusual, is the first time they log in after all those steps, it immediately returns them to the login page where they have to login again. it is like the site lost the first login. but then the second time it will go fine and they can proceed as normal. 2) explicit commits, rollbacks. according to massimo, web2py handles all that internally so on the surface, we should not be doing much explicit commits and rollbacks. so i don't have those calls in my code. 3) access to DBAPI cursor bypassing the DAL. i would have to write a separate app to do that to bypass all my code in order to bread it down to more basic SQL statements. i think. 4) check if psycopg2 is recent and compiled againsts libpq-9.1 that is good point. in fact, how do i know if web2py is using pg8000 or psycopg2? in fact both are on my machine. i think there is a syntax in the DAL for specifying which one. perhaps i should use one over the other. Also what kind of server configuration you have? rocket, apache+wsgi or ... apache+wsgi on a centos 6.3 server, old single core compaq at the moment. Does the error happen on a multicore machine and there are concurrent requests? See the pooling item above.. What we really need is a simplified version of your code that shows the same error. yes, i agree and i have backing off/commenting a lot of code to isolate the problem. but still baffled. mic --
[web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
the ticket frequency seems to be increasing. i put in regular linux cron to restart the httpd service in the morning, as well as, delete the sessions under that application. but i have been figuring out that if only occurs upon login, assuming the user is registered. and it seems to have something to do with clearing the cookies on the browser side. but not always. there is just a better chance of not getting the ticket if the cookies are clear and the sessions are erased. but still no real handle on any particular area of code within my app. so i am still at a loss; still wondering, almost desperate. lucas --
Re: [web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
lucas, I think you can try looking in postgresql logs. Change your postgresql.conf configuration file so that it logs all the queries or at least all the queries that cause errors. Instructions are inside the postgresql.conf comments. Then restart postgresql and check the logs. It will not give you the web2py code where the error happens, but looking at the sequence of queries you can get a closer idea of what happens and maybe find where that wrong query is created. mic 2012/9/6 lucas sjluk...@gmail.com: the ticket frequency seems to be increasing. i put in regular linux cron to restart the httpd service in the morning, as well as, delete the sessions under that application. but i have been figuring out that if only occurs upon login, assuming the user is registered. and it seems to have something to do with clearing the cookies on the browser side. but not always. there is just a better chance of not getting the ticket if the cookies are clear and the sessions are erased. but still no real handle on any particular area of code within my app. so i am still at a loss; still wondering, almost desperate. lucas -- --
[web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
ok, so i turned on debug5 in the postgres.conf file and restarted it. gives lots of entries. i then waited for that type ticket to arise again, it did, and traced to logs to that date/time stamp. the entries are below. i really can't see anything unusual except to say that it is occuring at login. i don't know exactly what kind of error postgres might give, but it looks like it commits and tidies up after the queries just fine. not really seeing any problem there and it only confirms that web2py is bugging during the login. lucas. 2012-09-06 19:51:07 EDT: [unknown]LOG: connection received: host=127.0.0.1 port=50185 2012-09-06 19:51:07 EDT: [unknown]DEBUG: postmaster child[27375]: starting with ( 2012-09-06 19:51:07 EDT: [unknown]DEBUG: postgres 2012-09-06 19:51:07 EDT: [unknown]DEBUG: weinstruct 2012-09-06 19:51:07 EDT: [unknown]DEBUG: ) 2012-09-06 19:51:07 EDT: [unknown]DEBUG: InitPostgres 2012-09-06 19:51:07 EDT: [unknown]DEBUG: my backend ID is 2 2012-09-06 19:51:07 EDT: [unknown]DEBUG: StartTransaction 2012-09-06 19:51:07 EDT: [unknown]DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2012-09-06 19:51:07 EDT: [unknown]DEBUG: received password packet 2012-09-06 19:51:07 EDT: [unknown]LOG: connection authorized: user=postgres database=weinstruct 2012-09-06 19:51:07 EDT: [unknown]DEBUG: CommitTransaction 2012-09-06 19:51:07 EDT: [unknown]DEBUG: name: unnamed; blockState: STARTED; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2012-09-06 19:51:07 EDT: [unknown]DEBUG: StartTransactionCommand 2012-09-06 19:51:07 EDT: [unknown]STATEMENT: BEGIN 2012-09-06 19:51:07 EDT: [unknown]DEBUG: StartTransaction 2012-09-06 19:51:07 EDT: [unknown]STATEMENT: BEGIN 2012-09-06 19:51:07 EDT: [unknown]DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children: 2012-09-06 19:51:07 EDT: [unknown]STATEMENT: BEGIN 2012-09-06 19:51:07 EDT: [unknown]DEBUG: ProcessUtility 2012-09-06 19:51:07 EDT: [unknown]STATEMENT: BEGIN 2012-09-06 19:51:07 EDT: [unknown]DEBUG: CommitTransactionCommand 2012-09-06 19:51:07 EDT: [unknown]STATEMENT: BEGIN 2012-09-06 19:51:07 EDT: [unknown]DEBUG: StartTransactionCommand 2012-09-06 19:51:07 EDT: [unknown]STATEMENT: SET standard_conforming_strings=on; 2012-09-06 19:51:07 EDT: [unknown]DEBUG: ProcessUtility 2012-09-06 19:51:07 EDT: [unknown]STATEMENT: SET standard_conforming_strings=on; 2012-09-06 19:51:07 EDT: [unknown]DEBUG: CommitTransactionCommand 2012-09-06 19:51:07 EDT: [unknown]STATEMENT: SET standard_conforming_strings=on; 2012-09-06 19:51:08 EDT: [unknown]DEBUG: StartTransactionCommand 2012-09-06 19:51:08 EDT: [unknown]STATEMENT: SELECT auth_user.id, auth_user.prefix_title, auth_user.first_name, auth_user.last_name, auth_user.nick_name, auth_user.city_state, auth_user.zip, auth_user.gender, auth_user.age, auth_user.birthdate, auth_user.name_of_college_or_university, auth_user.school_id, auth_user.degree_seeking, auth_user.email, auth_user.password, auth_user.registration_key, auth_user.reset_password_key, auth_user.registration_id, auth_user.professor, auth_user.create_lecture_request, auth_user.create_lecture_agreement, auth_user.create_lecture_foldername, auth_user.input_date FROM auth_user WHERE (auth_user.email = 'dykab...@yahoo.com'); 2012-09-06 19:51:08 EDT: [unknown]DEBUG: CommitTransactionCommand 2012-09-06 19:51:08 EDT: [unknown]STATEMENT: SELECT auth_user.id, auth_user.prefix_title, auth_user.first_name, auth_user.last_name, auth_user.nick_name, auth_user.city_state, auth_user.zip, auth_user.gender, auth_user.age, auth_user.birthdate, auth_user.name_of_college_or_university, auth_user.school_id, auth_user.degree_seeking, auth_user.email, auth_user.password, auth_user.registration_key, auth_user.reset_password_key, auth_user.registration_id, auth_user.professor, auth_user.create_lecture_request, auth_user.create_lecture_agreement, auth_user.create_lecture_foldername, auth_user.input_date FROM auth_user WHERE (auth_user.email = 'dykab...@yahoo.com'); 2012-09-06 19:51:08 EDT: [unknown]DEBUG: StartTransactionCommand 2012-09-06 19:51:08 EDT: [unknown]STATEMENT: SELECT auth_membership.id, auth_membership.user_id, auth_membership.group_id FROM auth_membership WHERE (auth_membership.user_id = 20); 2012-09-06 19:51:08 EDT: [unknown]DEBUG: CommitTransactionCommand 2012-09-06 19:51:08 EDT: [unknown]STATEMENT: SELECT auth_membership.id, auth_membership.user_id, auth_membership.group_id FROM auth_membership WHERE (auth_membership.user_id = 20); 2012-09-06 19:51:08 EDT: [unknown]DEBUG: StartTransactionCommand 2012-09-06 19:51:08 EDT: [unknown]STATEMENT: SELECT auth_group.id, auth_group.role, auth_group.description FROM auth_group WHERE (auth_group.id = 3) ORDER BY auth_group.id LIMIT 1 OFFSET 0; 2012-09-06 19:51:08 EDT: [unknown]DEBUG: CommitTransactionCommand
[web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
well, i am still having this fatal crash after login. i simplified my code, especially in layout.html to remove all instances of db, auth, and session. or checking for not None if i must like in session. i also scanned and checked index() and other start up pages or functions. are there anymore possible areas of danger i should be looking for because this instability is pretty bad? lucas --
[web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
When you say crash you meat a ticket, right? Try delete all of your session files. On Tuesday, 4 September 2012 13:11:23 UTC-5, lucas wrote: well, i am still having this fatal crash after login. i simplified my code, especially in layout.html to remove all instances of db, auth, and session. or checking for not None if i must like in session. i also scanned and checked index() and other start up pages or functions. are there anymore possible areas of danger i should be looking for because this instability is pretty bad? also, i think it may happen when cookies are clear or wrong, but i am not sure of this for sure. lucas --
[web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
yes, i mean ticket, sorry. should i just delete the session manually or should i do it programmatically? --
[web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
Can you show us the action that causes the problem? I suspect you have something like this: def youraction() try: do something with db except: do something else ... For some reason do something with db fails and closes the db cursor. It should be def youraction() try: do something with db except: db.rollback() do something else ... On Monday, 3 September 2012 04:25:31 UTC-5, lucas wrote: i have been having a problem with users logging in or registering. web2py seems to crash on some level and returns an internal error after the user hits submit upon registering or logging in. i was initially getting the error on my web2py version installed of 1.99.2, so i updated to the latest of 2.0.6, but i am still getting the crash. i am running postgresql 9.1 on the backend and centos 6 on the os. i am able to reproduce it. it doesn't seem to make a lot of sense to me, but it seems to be in the DAL database side of things. i got the traceback of: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. Traceback (most recent call last): File /opt/web-apps/web2py/gluon/main.py, line 562, in wsgibase session._try_store_on_disk(request, response) File /opt/web-apps/web2py/gluon/globals.py, line 683, in _try_store_on_disk cPickle.dump(dict(self), response.session_file) File /usr/lib/python2.6/copy_reg.py, line 74, in _reduce_ex getstate = self.__getstate__ File /opt/web-apps/web2py/gluon/dal.py, line 7287, in __getattr__ self.__allocate() File /opt/web-apps/web2py/gluon/dal.py, line 7280, in __allocate self._record = self._table[int(self)] File /opt/web-apps/web2py/gluon/dal.py, line 7565, in __getitem__ return self._db(self._id == key).select(limitby=(0,1)).first() File /opt/web-apps/web2py/gluon/dal.py, line 8697, in select return adapter.select(self.query,fields,attributes) File /opt/web-apps/web2py/gluon/dal.py, line 1577, in select return self._select_aux(sql,fields,attributes) File /opt/web-apps/web2py/gluon/dal.py, line 1550, in _select_aux self.execute(sql) File /opt/web-apps/web2py/gluon/dal.py, line 1653, in execute return self.log_execute(*a, **b) File /opt/web-apps/web2py/gluon/dal.py, line 1647, in log_execute ret = self.cursor.execute(*a, **b) InterfaceError: cursor already closed --
[web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
ok, i have tons of db() accesses throughout a few thousand lines of code. thinking out loud, but since it has to do with session and/or logging in and registering, then i can begin with the initial screens wherein the cookies or such may be reset and such. i have a few ideas of where, and in those areas i will capture exceptions and rollback as suggested. what exactly is the exception for the db or DAL? like try: some code except DBException on e: db.rollback() return 'db exception: %s' % e just so that i can at least return more tracking information also. lucas --
[web2py] Re: internal error crash with newest 2.0.6 and old 1.99.2
The problem is this. Suppose you try do something that the db does not allow. For example insert a duplicate record or invalid sql etc. The database server will complain and expects you to rollback the transaction. If you do not rollback and try any other db operation, it will close the connection. Normally this is handled automatically by web2py but since you are getting that error I assume you may be bypassing the mechanism. A try except would by pass the mechanism because it would prevent web2py from detecting and db error and would continue execution. On Monday, 3 September 2012 09:37:46 UTC-5, lucas wrote: ok, i have tons of db() accesses throughout a few thousand lines of code. thinking out loud, but since it has to do with session and/or logging in and registering, then i can begin with the initial screens wherein the cookies or such may be reset and such. i have a few ideas of where, and in those areas i will capture exceptions and rollback as suggested. what exactly is the exception for the db or DAL? like try: some code except DBException on e: db.rollback() return 'db exception: %s' % e just so that i can at least return more tracking information also. lucas --
