Opened 10 years ago

Closed 3 years ago

#8770 closed defect (wontfix)

Jump to invalid address in tcl plugin

Reported by: cavedon Owned by: elb
Milestone: Component: plugins
Version: 2.5.5 Keywords:
Cc:

Description

The Tcl library, invoked by the tcl plugin, install a destructor function which is called when the invoking thread is destroyed. This happens in tclUnixThrd.c, TclpGetAllocCache?()

pthread_key_create(&key, TclpFreeAllocCache);

Right now, if you call purple_core_quit(), the tcl.so library gets unloaded, so when the thread is destroyed, the no longer existent TclpFreeAllocCache?() will be called.

I am attaching patch that uses the same hack as perl plugin to prevent unloading of tcl.so.

Attachments (2)

tcl-no-unload.patch (791 bytes) - added by cavedon 10 years ago.
tcl-nodelete.patch (382 bytes) - added by cavedon 9 years ago.

Download all attachments as: .zip

Change History (12)

Changed 10 years ago by cavedon

comment:1 Changed 10 years ago by datallah

  • Owner set to elb

comment:2 follow-up: Changed 10 years ago by bernmeister

Can/should this patch be moved to Patches Needing Review?

comment:3 in reply to: ↑ 2 Changed 10 years ago by cavedon

Replying to bernmeister:

Can/should this patch be moved to Patches Needing Review?

If you are asking me, I would be happy to see this patch reviewed and merged! Thanks!

comment:4 follow-up: Changed 10 years ago by elb

Hmm, I thought I had commented on this before. I have reviewed this patch. Perhaps we discussed it on IRC?

I spent some time looking at the Tcl API to see if I could figure out how to prevent it from installing that exit handler, and didn't see an immediate solution. This patch is not really a fix to the problem, so I hate to see it go in. I did not mean to let it sit this long, though.

comment:5 in reply to: ↑ 4 Changed 10 years ago by cavedon

Replying to elb:

Hmm, I thought I had commented on this before. I have reviewed this patch. Perhaps we discussed it on IRC?

Not with me :)

I spent some time looking at the Tcl API to see if I could figure out how to prevent it from installing that exit handler, and didn't see an immediate solution. This patch is not really a fix to the problem, so I hate to see it go in. I did not mean to let it sit this long, though.

I did not see an easy way to fix this either... Thanks!

comment:6 follow-up: Changed 10 years ago by deryni

Is this the same thing? I imagine -z nodelete to be roughly equivalent to the g_module_open refcount hackery and so likely has a similar bad taste.

Changed 9 years ago by cavedon

comment:7 in reply to: ↑ 6 Changed 9 years ago by cavedon

Replying to deryni:

Is this the same thing? I imagine -z nodelete to be roughly equivalent to the g_module_open refcount hackery and so likely has a similar bad taste.

Yes, it is the same issue. I think -z nodelete is a better solution and not an hackery. I have attached a patch. Tested it and fixes the issue.

Please merge this patch, as I am stumbling upon this bug again, with qutecom.

comment:8 follow-up: Changed 9 years ago by elb

Does -z nodelete puke on non-GNU linkers? (I suspect it does.) Is the init hack likely to be more portable, for that reason? I also suspect that more Pidgin-supported platforms are using gcc than not, and there's already a fix in there for Sun cc.

comment:9 in reply to: ↑ 8 Changed 9 years ago by cavedon

Replying to elb:

Does -z nodelete puke on non-GNU linkers? (I suspect it does.) Is the init hack likely to be more portable, for that reason? I also suspect that more Pidgin-supported platforms are using gcc than not, and there's already a fix in there for Sun cc.

Probably you are right. Well, at this point the init hack is known to be working on all arch... I am fine with both, as long as there is something to prevent the tcl library to be unloaded :)

Thanks!

comment:10 Changed 3 years ago by grim

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

tcl is no longer supported in 3.0.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!