1

我有一个不幸的任务是维护一个孤立的 Perl 程序，该程序使用 Perl/TK 创建 GUI，并在某些情况下崩溃并出现错误，例如

*** glibc detected *** /usr/bin/perl: corrupted double-linked list: 0x0000000003daf500 ***

Perl 程序是否有可能包含导致这种行为的错误，或者我可以安全地假设 Perl 解释器和/或 Perl/Tk 中的错误负责并等待这些工具的新版本可能是最好的方法摆脱这个问题？

编辑：为了让我的问题更清楚：尝试两次销毁小部件或在已销毁的小部件上调用方法等错误是否会导致干净的错误消息，或者是否会导致我遇到的问题？

EDIT2：Perl 版本是 5.10.0/x86_64-linux-thread-multi

它使用这个模块：

use Tie::Watch;
use Tk;
use Tk::Balloon;
use Tk::Compound;
use Tk::DialogBox;
use Tk::LabFrame;
use Tk::NoteBook;
use Tk::Pane;
use Tk::ROText;
use DBI;
use Data::Dumper;
use XML::Simple::DTDReader;
4

1 回答 1

4

是的，这是可能的，但在这种情况下不太可能。

在 Perl（以及任何编程语言）中有多种方法可以直接访问（和修改）程序内存。对此有扩展（Win32::Process::Memory for Windows），但在 Linux 下，最简单的方法是打开 /proc/ pid /map（进程内存，映射到随机访问文件）并对其进行操作。

所以，绝对有可能。

然而，您的 Perl 程序不太可能使用这些技巧中的任何一个来直接操作它自己的内存。如您所想，最可能的罪魁祸首是使用的库之一（在本例中为 Tk）。

您可以尝试使用Devel::Trace模块来查看程序在崩溃之前尝试执行的操作。

如果您发现它总是在特定行崩溃，您可以尝试更改其行为以避免触发底层库中的错误。不过，这有点碰巧。

如果有人知道 Perl/Tk 中的这种错误，那可能会有所帮助。您的程序是否使用了其他使用 C 库的库（例如，不是“纯 perl”库）而不是 Tk？

于 2012-09-07T06:49:22.850 回答