Code

Opened 6 years ago

Closed 6 years ago

Last modified 3 years ago

#8020 closed (fixed)

python process crashes when using sitemaps after [8088]

Reported by: Boo Owned by: nobody
Component: Contrib apps Version: master
Severity: Keywords: sitemap
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description (last modified by mtredinnick)

When I go to http://example.com/sitemap.xml, python process crashes without any errors or core dumps.

Django-version: trunk after [8088]
DB-backends: PostgreSQL or SQLite3
URLs in sitemap: less than 50000

Attachments (3)

testcase.tar.gz (5.7 KB) - added by Boo 6 years ago.
TestCase to repeat the problem
testcase2.tar.gz (5.6 KB) - added by Boo 6 years ago.
Corrected INSTALLED_APPS
sitemap-crash.diff (693 bytes) - added by johndagostino 6 years ago.
fixes development server crash sitemaps framework

Download all attachments as: .zip

Change History (18)

comment:1 Changed 6 years ago by mtredinnick

  • Description modified (diff)
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

There isn't really enough information here to work out what's going on or what the problem being reported is. You say "it crashed", but what do you mean? How can we replicate the problem? Do you have a small example that shows what is going on?

A problem that cannot be repeated cannot be fixed.

Changed 6 years ago by Boo

TestCase to repeat the problem

comment:2 Changed 6 years ago by Boo

I've added TestCase to repeat this problem.
I use Python-2.5.2, OS: FreeBSD and MacOSX.

I run development server and go to http://127.0.0.1:8000/sitemap.xml, and devserver crushes without any errors.

Boo:~/projects/testcase boo$ ./manage.py runserver
Validating models...
0 errors found

Django version 1.0-alpha-SVN-8138, using settings 'testcase.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
Boo:~/projects/testcase boo$

comment:3 Changed 6 years ago by Boo

  • Needs tests set

comment:4 Changed 6 years ago by evan_schulz

As long as I add "django.contrib.sitemaps" to INSTALLED_APPS the attached test case works fine for me: displaying the sitemap file without any sign of errors or crashing. I happen to be at changeset [8156] on python 2.5.2.

Changed 6 years ago by Boo

Corrected INSTALLED_APPS

comment:5 Changed 6 years ago by julianb

The test case works for me. Python 2.5.2 at [8161]

Changed 6 years ago by johndagostino

fixes development server crash sitemaps framework

comment:6 Changed 6 years ago by johndagostino

I can reproduce this on MacOSX with Python 2.5.1 The attached patch fixes the crash for me.

from django.contrib.sitemaps import Sitemap
from blog.models import Post

class PostSitemap(Sitemap):
    changefreq = "never"
    priority = 0.5

    def items(self):
        return Post.objects.all()

    def lastmod(self, obj):
        return obj.pub_date

comment:7 Changed 6 years ago by johndagostino

  • Has patch set
  • milestone set to 1.0 beta
  • Needs tests unset

comment:8 Changed 6 years ago by julianb

  • Triage Stage changed from Unreviewed to Ready for checkin

Seems obvious...

comment:9 Changed 6 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from new to closed

(In [8231]) Fixed #8020 -- Fixed paginator initialisation in sitemaps framework. Thanks,
John D'Agostino.

comment:10 Changed 6 years ago by hvendelbo

  • Resolution fixed deleted
  • Status changed from closed to reopened

This change recurses for me on Mac OSX, I don't understand why it wouldn't infinitely recurse on all platforms???

Is it because I changed the Sitemap class to a new-style class?

get_urls gets the paginator entering _get_paginator
It already has the property paginator, so
it returns the property paginator which triggers a call to _get_paginator
as it already has ....

comment:11 Changed 6 years ago by hvendelbo

I believe reverting the fix and making Sitemaps new-style classes fixes the cause of this ticket.

comment:12 Changed 6 years ago by mtredinnick

  • milestone changed from 1.0 beta to 1.0

comment:13 Changed 6 years ago by mtredinnick

  • Triage Stage changed from Ready for checkin to Accepted

comment:14 Changed 6 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from reopened to closed

From your description, it sounds like you are running a version from earlier than [8231], where the infinite loop problem with referring to a bad attribute was fixed. So I'm going to reclose this.

If you are still seeing a problem on unmodified code that is up to date, please open a new ticket explaining how to repeat the problem.

comment:15 Changed 3 years ago by jacob

  • milestone 1.0 deleted

Milestone 1.0 deleted

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.