on latest svn am getting a type error TypeError: argument 1 must be str, not unicode
Kenneth Gonsalves
hi,
on upgrading to the latest svn I am getting a sporadic error like this: TypeError: argument 1 must be str, not unicode. On runserver, the full traceback is this:
Traceback (most recent call last):
File "/home/dtc/dtcproject/env/lib/python2.5/site-packages/django/core/servers/basehttp.py", line 280, in run
self.result = application(self.environ, self.start_response)
File "/home/dtc/dtcproject/env/lib/python2.5/site-packages/django/core/servers/basehttp.py", line 674, in __call__
return self.application(environ, start_response)
File "/home/dtc/dtcproject/env/lib/python2.5/site-packages/django/core/handlers/wsgi.py", line 245, in __call__
response = middleware_method(request, response)
File "/home/dtc/dtcproject/env/lib/python2.5/site-packages/django/contrib/sessions/middleware.py", line 36, in process_response
request.session.save()
File "/home/dtc/dtcproject/env/lib/python2.5/site-packages/django/contrib/sessions/backends/db.py", line 63, in save
obj.save(force_insert=must_create)
File "/home/dtc/dtcproject/env/lib/python2.5/site-packages/django/db/models/base.py", line 430, in save
self.save_base(using=using, force_insert=force_insert, force_update=force_update)
File "/home/dtc/dtcproject/env/lib/python2.5/site-packages/django/db/models/base.py", line 492, in save_base
manager.using(using).filter(pk=pk_val).exists())):
File "/home/dtc/dtcproject/env/lib/python2.5/site-packages/django/db/models/query.py", line 491, in exists
return self.query.has_results(using=self.db)
File "/home/dtc/dtcproject/env/lib/python2.5/site-packages/django/db/models/sql/query.py", line 389, in has_results
return bool(compiler.execute_sql(SINGLE))
File "/home/dtc/dtcproject/env/lib/python2.5/site-packages/django/db/models/sql/compiler.py", line 740, in execute_sql
cursor.execute(sql, params)
File "/home/dtc/dtcproject/env/lib/python2.5/site-packages/django/db/backends/util.py", line 19, in execute
return self.cursor.execute(sql, params)
File "/home/dtc/dtcproject/env/lib/python2.5/site-packages/django/db/backends/postgresql/base.py", line 57, in execute
return self.cursor.execute(sql, params)
TypeError: argument 1 must be str, not unicode
--
regards
Kenneth Gonsalves
Senior Project Officer
NRC-FOSS
Kenneth Gonsalves
> on upgrading to the latest svn I am getting a sporadic error like this:
> TypeError: argument 1 must be str, not unicode. On runserver, the full
> traceback is this:
>
I went back to 12300 - same problem, but 12200 is ok.
Russell Keith-Magee
> On Tuesday 02 Feb 2010 4:04:15 pm Kenneth Gonsalves wrote:
>> on upgrading to the latest svn I am getting a sporadic error like this:
>> TypeError: argument 1 must be str, not unicode. On runserver, the full
>> traceback is this:
>>
>
> I went back to 12300 - same problem, but 12200 is ok.
Kenneth - we need two things:
* A *specific* revision that breaks things. You only need to do 8
checks to find a specific revision between 12300 and 12200 if you do a
bisection search.
* The input that is causing things to break. "Sporadic error" and a
stack trace doesn't really help us identify a problem. The problem
isn't sporadic for the case that is causing it to fail. We just don't
know what that case is.
The test suite isn't currently showing any failures, so obviously
we're allowing unicode to be passed to a cursor where previously it
was prevented. We need to know exactly what you are doing to cause
this problem to occur.
Yours,
Russ Magee %-)
Kenneth Gonsalves
> > I went back to 12300 - same problem, but 12200 is ok.
>
> Kenneth - we need two things:
>
> checks to find a specific revision between 12300 and 12200 if you do a
> bisection search.
>
will do it - had to get back into production so could not do it yesterday, and
the errors all seem to do with postgresql, but will get back with specific
errors some time today.
Kenneth Gonsalves
> >
> > I went back to 12300 - same problem, but 12200 is ok.
>
> Kenneth - we need two things:
>
> checks to find a specific revision between 12300 and 12200 if you do a
> bisection search.
revision 12352 breaks
>
> * The input that is causing things to break. "Sporadic error" and a
> stack trace doesn't really help us identify a problem. The problem
> isn't sporadic for the case that is causing it to fail. We just don't
> know what that case is.
>
the error occurs on any page that hits the database - it differs depending on
the database query. Here is an error generated by two sites:
traceback
Environment:
Request Method: GET
Request URL: http://127.0.0.1:8000/
Django Version: 1.2 alpha 1 SVN-12352
Python Version: 2.6.0
Installed Applications:
['django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.admin',
'djangogolf.web']
Installed Middleware:
('django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.middleware.locale.LocaleMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware')
Traceback:
File "/usr/lib/python2.6/django/core/handlers/base.py" in get_response
80. response = middleware_method(request)
File "/usr/lib/python2.6/django/middleware/locale.py" in process_request
16. language = translation.get_language_from_request(request)
File "/usr/lib/python2.6/django/utils/translation/__init__.py" in
get_language_from_request
97. return real_get_language_from_request(request)
File "/usr/lib/python2.6/django/utils/translation/trans_real.py" in
get_language_from_request
354. lang_code = request.session.get('django_language', None)
File "/usr/lib/python2.6/django/contrib/sessions/backends/base.py" in get
63. return self._session.get(key, default)
File "/usr/lib/python2.6/django/contrib/sessions/backends/base.py" in
_get_session
172. self._session_cache = self.load()
File "/usr/lib/python2.6/django/contrib/sessions/backends/db.py" in load
21. expire_date__gt=datetime.datetime.now()
File "/usr/lib/python2.6/django/db/models/manager.py" in get
132. return self.get_query_set().get(*args, **kwargs)
File "/usr/lib/python2.6/django/db/models/query.py" in get
334. num = len(clone)
File "/usr/lib/python2.6/django/db/models/query.py" in __len__
79. self._result_cache = list(self.iterator())
File "/usr/lib/python2.6/django/db/models/query.py" in iterator
267. for row in compiler.results_iter():
File "/usr/lib/python2.6/django/db/models/sql/compiler.py" in results_iter
685. for rows in self.execute_sql(MULTI):
File "/usr/lib/python2.6/django/db/models/sql/compiler.py" in execute_sql
740. cursor.execute(sql, params)
File "/usr/lib/python2.6/django/db/backends/util.py" in execute
19. return self.cursor.execute(sql, params)
File "/usr/lib/python2.6/django/db/backends/postgresql/base.py" in execute
57. return self.cursor.execute(query, args)
Exception Type: NameError at /
Exception Value: global name 'query' is not defined
Kenneth Gonsalves
> > * The input that is causing things to break. "Sporadic error" and a
> > stack trace doesn't really help us identify a problem. The problem
> > isn't sporadic for the case that is causing it to fail. We just don't
> > know what that case is.
> >
>
> the error occurs on any page that hits the database - it differs depending
> on the database query. Here is an error generated by two sites:
>
the code used is here:
http://bitbucket.org/lawgon/csrftest/src/
Russell Keith-Magee
This isn't the same problem that you originally reported. This
particular problem was logged as #12732, and fixed in [12359].
I would also note that you previously said that the problem was
between [12200] and [12300] - why are you reporting [12352] as the
problem revision?
Yours
Russ Magee %-)
Kenneth Gonsalves
> > Exception Type: NameError at /
> > Exception Value: global name 'query' is not defined
>
> This isn't the same problem that you originally reported. This
> particular problem was logged as #12732, and fixed in [12359].
this problem occurs for me from the reported revision and is still occuring
with the latest svn - 12377, and as I said the error messages differ depending
on the page loaded. I have copied the error message occuring in latest svn
using the test setup which I have posted in another post on this thread.
>
> I would also note that you previously said that the problem was
> between [12200] and [12300] - why are you reporting [12352] as the
> problem revision?
>
yesterday I was in panic mode - I kept going downwards until I got a revision
that worked - which was 12200. 12300 did not work, but I did not test it
thoroughly. Today, on thorough testing of 12300, it did work, and I zeroed in
on 12352. I have not tested all the revisions between 12352 and current trunk,
but all those I have tested did not work. The traceback on admin for my test
site is here:
Environment:
Request Method: GET
Request URL: http://127.0.0.1:8000/admin/
Django Version: 1.2 alpha 1 SVN-12377
Python Version: 2.6.0
Installed Applications:
['django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.admin',
'csrftest.web']
Installed Middleware:
('django.middleware.csrf.CsrfViewMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware')
Traceback:
File "/usr/lib/python2.6/django/core/handlers/base.py" in get_response
101. response = callback(request, *callback_args,
**callback_kwargs)
File "/usr/lib/python2.6/django/contrib/admin/sites.py" in wrapper
206. return self.admin_view(view, cacheable)(*args,
**kwargs)
File "/usr/lib/python2.6/django/utils/decorators.py" in __call__
36. return self.decorator(self.func)(*args, **kwargs)
File "/usr/lib/python2.6/django/utils/decorators.py" in _wrapped_view
86. response = view_func(request, *args, **kwargs)
File "/usr/lib/python2.6/django/utils/decorators.py" in __call__
36. return self.decorator(self.func)(*args, **kwargs)
File "/usr/lib/python2.6/django/views/decorators/cache.py" in
_wrapped_view_func
70. response = view_func(request, *args, **kwargs)
File "/usr/lib/python2.6/django/contrib/admin/sites.py" in inner
188. if not self.has_permission(request):
File "/usr/lib/python2.6/django/contrib/admin/sites.py" in has_permission
145. return request.user.is_active and request.user.is_staff
File "/usr/lib/python2.6/django/contrib/auth/middleware.py" in __get__
9. request._cached_user = get_user(request)
File "/usr/lib/python2.6/django/contrib/auth/__init__.py" in get_user
97. user_id = request.session[SESSION_KEY]
File "/usr/lib/python2.6/django/contrib/sessions/backends/base.py" in
__getitem__
46. return self._session[key]
File "/usr/lib/python2.6/django/contrib/sessions/backends/base.py" in
_get_session
172. self._session_cache = self.load()
File "/usr/lib/python2.6/django/contrib/sessions/backends/db.py" in load
21. expire_date__gt=datetime.datetime.now()
File "/usr/lib/python2.6/django/db/models/manager.py" in get
132. return self.get_query_set().get(*args, **kwargs)
File "/usr/lib/python2.6/django/db/models/query.py" in get
334. num = len(clone)
File "/usr/lib/python2.6/django/db/models/query.py" in __len__
79. self._result_cache = list(self.iterator())
File "/usr/lib/python2.6/django/db/models/query.py" in iterator
267. for row in compiler.results_iter():
File "/usr/lib/python2.6/django/db/models/sql/compiler.py" in results_iter
685. for rows in self.execute_sql(MULTI):
File "/usr/lib/python2.6/django/db/models/sql/compiler.py" in execute_sql
740. cursor.execute(sql, params)
File "/usr/lib/python2.6/django/db/backends/util.py" in execute
19. return self.cursor.execute(sql, params)
File "/usr/lib/python2.6/django/db/backends/postgresql/base.py" in execute
57. return self.cursor.execute(sql, params)
Exception Type: DatabaseError at /admin/
Exception Value: ERROR: syntax error at or near "11"
LINE 1: ... AND "django_session"."expire_date" > 2010-02-03 11:10:34.2...
^
SELECT "django_session"."session_key", "django_session"."session_data",
"django_session"."expire_date" FROM "django_session" WHERE
("django_session"."session_key" = '7590eb0f5db8bf2ff3c84374b4aa1fb7' AND
"django_session"."expire_date" > 2010-02-03 11:10:34.298195 )
Russell Keith-Magee
> On Wednesday 03 Feb 2010 10:09:44 am Russell Keith-Magee wrote:
>> > Exception Type: NameError at /
>> > Exception Value: global name 'query' is not defined
>>
>> This isn't the same problem that you originally reported. This
>> particular problem was logged as #12732, and fixed in [12359].
>
> this problem occurs for me from the reported revision and is still occuring
> with the latest svn - 12377, and as I said the error messages differ depending
> on the page loaded. I have copied the error message occuring in latest svn
> using the test setup which I have posted in another post on this thread.
>>
>> I would also note that you previously said that the problem was
>> between [12200] and [12300] - why are you reporting [12352] as the
>> problem revision?
>>
>
> yesterday I was in panic mode - I kept going downwards until I got a revision
> that worked - which was 12200. 12300 did not work, but I did not test it
> thoroughly. Today, on thorough testing of 12300, it did work, and I zeroed in
> on 12352. I have not tested all the revisions between 12352 and current trunk,
> but all those I have tested did not work. The traceback on admin for my test
> site is here:
Ok - seriously - if you want help debugging this, you need to get your
story straight.
You have now reported 3 completely different stack traces.
Your initial report gave this stack trace:
-------------------------
django/db/backends/postgresql/base.py", line 57, in execute
return self.cursor.execute(sql, params)
TypeError: argument 1 must be str, not unicode
-------------------------
You are yet to provide the revision and conditions under which this bug occurs.
Your second report gave this stack trace:
-------------------------
File "/usr/lib/python2.6/django/db/backends/postgresql/base.py" in execute
57. return self.cursor.execute(query, args)
Exception Type: NameError at /
Exception Value: global name 'query' is not defined
-------------------------
This is the problem reported as #12732, and fixed in [12359]. Any
attempt to use a revision between [12352] and [12359] will fail with
this error if you're using the postgres database backend.
In your most recent report, you describe the following:
-------------------------
File "/usr/lib/python2.6/django/db/backends/postgresql/base.py" in execute
57. return self.cursor.execute(sql, params)
Exception Type: DatabaseError at /admin/
Exception Value: ERROR: syntax error at or near "11"
LINE 1: ... AND "django_session"."expire_date" > 2010-02-03 11:10:34.2...
^
-------------------------
You say that this problem occurs on the current trunk, but you haven't
said what I have to do to reproduce this problem.
Which of these problems are you *actually* having? And please, don't
rush to answering. I really do want to help you identify the cause of
this problem - especially if it has been caused by a recent commit -
but my patience for wading through inconsistent bug reports is
limited. At some point, I will give up and declare the problem
'worksforme'.
Yours,
Russ Magee %-)
Kenneth Gonsalves
> Ok - seriously - if you want help debugging this, you need to get your
> story straight.
>
please believe me - I *am* trying. Ok, lets try to be straight:
1. site used for testing: http://bitbucket.org/lawgon/csrftest/src/
2. site crashes in 12352, 12359,12360 and current trunk and in every revision
in between that I have tested. Works perfectly in 12351. I get the same crash
but varying errors on all other sites. The original error in the subject line
was obtained from a platform of nginx+tornado, which I have stopped using due
to csrf and other problems. There are also a huge number of imports in the
test site, one of which may cause the error.
3. platform - run server
4. two different errors occur, one for 127.0.0.1:8000/admin/ and the other when
clicking the submit button on 127.0.0.1/addtest/
the two errors are:
from admin (on attempting to load admin):
Environment:
File "/usr/lib/python2.6/django/db/backends/postgresql/base.py" in execute
57. return self.cursor.execute(sql, params)
Exception Type: DatabaseError at /admin/
Exception Value: ERROR: syntax error at or near "12"
LINE 1: ... AND "django_session"."expire_date" > 2010-02-03 12:07:11.1...
^
SELECT "django_session"."session_key", "django_session"."session_data",
"django_session"."expire_date" FROM "django_session" WHERE
("django_session"."session_key" = '2730ca9cb60f3ba6db7815c8aba7f166' AND
"django_session"."expire_date" > 2010-02-03 12:07:11.167451 )
from the /addtest/ on pressing submit:
Environment:
Request Method: POST
Request URL: http://127.0.0.1:8000/addtest/
Django Version: 1.2 alpha 1 SVN-12377
Python Version: 2.6.0
Installed Applications:
['django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.admin',
'csrftest.web']
Installed Middleware:
('django.middleware.csrf.CsrfViewMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware')
Traceback:
File "/usr/lib/python2.6/django/core/handlers/base.py" in get_response
101. response = callback(request, *callback_args,
**callback_kwargs)
File "/home/lawgon/projects/csrftest/../csrftest/web/views.py" in addtest
37. fm = form.save()
File "/usr/lib/python2.6/django/forms/models.py" in save
347. fail_message, commit, construct=False)
File "/usr/lib/python2.6/django/forms/models.py" in save_instance
95. instance.save()
File "/usr/lib/python2.6/django/db/models/base.py" in save
430. self.save_base(using=using, force_insert=force_insert,
force_update=force_update)
File "/usr/lib/python2.6/django/db/models/base.py" in save_base
519. result = manager._insert(values,
return_id=update_pk, using=using)
File "/usr/lib/python2.6/django/db/models/manager.py" in _insert
195. return insert_query(self.model, values, **kwargs)
File "/usr/lib/python2.6/django/db/models/query.py" in insert_query
1428. return query.get_compiler(using=using).execute_sql(return_id)
File "/usr/lib/python2.6/django/db/models/sql/compiler.py" in execute_sql
796. cursor = super(SQLInsertCompiler, self).execute_sql(None)
File "/usr/lib/python2.6/django/db/models/sql/compiler.py" in execute_sql
740. cursor.execute(sql, params)
File "/usr/lib/python2.6/django/db/backends/util.py" in execute
19. return self.cursor.execute(sql, params)
File "/usr/lib/python2.6/django/db/backends/postgresql/base.py" in execute
57. return self.cursor.execute(sql, params)
Exception Type: DatabaseError at /addtest/
Exception Value: ERROR: column "xwa" does not exist
LINE 1: INSERT INTO "web_testmodel" ("name") VALUES (xwa)
^
INSERT INTO "web_testmodel" ("name") VALUES (xwa)
Russell Keith-Magee
> On Wednesday 03 Feb 2010 11:44:36 am Russell Keith-Magee wrote:
>> Ok - seriously - if you want help debugging this, you need to get your
>> story straight.
>
> please believe me - I *am* trying. Ok, lets try to be straight:
>
Ok - try an update to r12378. Karen Tracey noticed a regression in the
way the cursor was handled which looks like it might explain the
problems you are having.
Yours,
Russ Magee %-)
Kenneth Gonsalves
> On Wed, Feb 3, 2010 at 2:41 PM, Kenneth Gonsalves <law...@au-kbc.org> wrote:
> > On Wednesday 03 Feb 2010 11:44:36 am Russell Keith-Magee wrote:
> >> Ok - seriously - if you want help debugging this, you need to get your
> >> story straight.
> >
>
> Ok - try an update to r12378. Karen Tracey noticed a regression in the
> way the cursor was handled which looks like it might explain the
> problems you are having.
>
ok - works now, thanks for your patience