2010-01-06 22 views
5

Ứng dụng của tôi đã gặp lỗi gần đây trên máy tính của khách hàng. Tôi nghi ngờ đó là do quản lý bộ nhớ của PyQt, điều này có thể dẫn đến việc truy cập bộ nhớ không hợp lệ khi không được xử lý đúng cách.Tôi có thể tìm ra nơi ứng dụng Python bị lỗi khi sử dụng đổ dữ liệu không?

Khi Python bị treo như thế này, không có dấu vết được in, chỉ một bãi chứa dữ liệu được ghi vào đĩa.

Có khả năng tìm ra vị trí trong mã Python xảy ra sự cố không?

Đây là bãi chứa: http://pastie.org/768550

Trả lời

6

Đây có phải là vùng chứa lõi Linux không? Nếu vậy bạn có thể kiểm tra nó với gdb. Bạn sẽ cần phải chạy trên một hệ thống với một hệ điều hành giống hệt nhau và phiên bản của Python, bao gồm cả thư viện của bên thứ 3. Chạy gdb -c /path/to/core/file. Khi gdb đã tải xong, lệnh bt sẽ liệt kê theo dõi ngăn xếp cho chuỗi chính và thread apply all bt sẽ liệt kê theo dõi ngăn xếp cho tất cả các chuỗi.

Điều này sẽ phụ thuộc vào việc phiên bản Python có bao gồm bảng biểu tượng đầy đủ hay không. . Tuy nhiên điều này vẫn có thể được sử dụng một số trong chẩn đoán những gì đã đi sai.

Nếu đó là một số hệ điều hành khác không hỗ trợ gdb thì bạn đang ở trên của riêng bạn - có lẽ hệ điều hành sẽ có các công cụ gỡ lỗi riêng.

Edit:

Có một trang trên wiki Python mô tả how to get a python stack trace with gdb.

Tuy nhiên, hãy xem nhanh liên kết trong câu hỏi cho biết hệ điều hành là Windows, do đó gdb không được sử dụng. Các thông tin trong Windows dump là tối thiểu, vì vậy tôi nghĩ rằng bạn đang ra khỏi may mắn.

gợi ý duy nhất của tôi là:

  1. cố gắng để tái tạo các tai nạn trong nhà.

  2. khiến người dùng tạo lại lỗi trong khi chạy một công cụ sẽ bắt gặp sự cố và thực hiện kết xuất bộ nhớ thích hợp. Đó là khoảng một thập kỷ kể từ khi tôi đã làm cửa sổ gỡ lỗi nghiêm trọng vì vậy tôi không biết những gì các công cụ có sẵn ngay bây giờ - có sử dụng được gọi là Dr.Watson, nhưng nó có thể là lỗi thời.

Nếu người dùng không thể tái tạo sự cố thì bạn sẽ không may mắn nếu nó không bao giờ xảy ra lại không phải là vấn đề lớn. ;-)

Cập nhật:

Google nói với tôi rằng Tiến sĩ Watson vẫn là xử lý vụ tai nạn mặc định trên Windows XP (và các phiên bản có lẽ khác của Windows) - stack dump đó có liên quan trong câu hỏi có thể đến từ nó. Tuy nhiên dữ liệu mặc định được lưu bởi Dr Watson là khá nhỏ, nhưng bạn có thể cấu hình nó để tiết kiệm hơn - xem this article. Tóm lại, nếu bạn chạy drwtsn32 -i nó sẽ bật lên một hộp thoại để cho phép bạn thiết lập các tùy chọn.

+0

không, không phải linux chắc chắn (xem danh sách quá trình trong bãi chứa: P) – shylent

+0

Tôi thực sự quan tâm đến một backtrace _Python_, mà tôi không thể sử dụng gdb tôi nghĩ. (Biểu tượng cho bãi chứa là có thể tôi nghĩ.) –

+0

Tôi đã cố gắng sao chép nó trên máy của người dùng, không hoạt động. Tôi có nghĩa là có một sự thay đổi của 0,00001001 rằng bộ nhớ của người dùng bị hỏng hoặc Windows hơi say lên. –

0

Ứng dụng của bạn có tạo nhật ký không? Nếu có, bạn có thể ghi nhật ký để tạo ra một bản ghi trong bộ nhớ mà bạn có thể tìm thấy trong vùng kết xuất lõi.Ngoài ra, bạn có thể yêu cầu họ tự gửi cho mình tệp nhật ký thay vì của kết xuất lõi.

1

Có một tệp có tên gdbinit trong cây nguồn Python (trong Misc/gdbinit) cung cấp một tập các macro cho gdb để hiển thị ngữ cảnh thông dịch hiện tại. Chỉ cần nhập source gdbinit vào gdb và sau đó bạn có thể thực thi các macro như pystack. Danh sách các macro có sẵn có thể được lấy đơn giản bằng cách đọc mã nguồn của tệp. (bạn có thể tìm thấy trực tiếp tại đây: http://svn.python.org/view/python/trunk/Misc/gdbinit?view=log).

Tất nhiên, nếu tai nạn quá nghiêm trọng đến mức nó đã làm hỏng cấu trúc bên trong của trình thông dịch, các macro có thể bị lỗi hoặc bị lỗi. Ngoài ra, tốt hơn là biên dịch trình thông dịch trong chế độ gỡ lỗi, nếu không gdb có thể không tìm được các biểu tượng và biến được yêu cầu.

1

Không chắc chắn nếu nó có ích, nhưng nếu bạn có thể bắt ngoại lệ, bạn có thể sử dụng http://github.com/gooli/pydump để lưu trữ kết xuất và tải nó sau trong trình gỡ lỗi Python.

Các vấn đề liên quan