Opened 9 years ago

Closed 9 years ago

Last modified 7 years ago

#7853 closed defect (duplicate)

PHP/Pidgin Aspell conflict causing crash on start up

Reported by: BoneBreaker Owned by: lschiere
Milestone: Component: unclassified
Version: 2.5.3 Keywords: PHP Aspell
Cc:

Description (last modified by BoneBreaker)

PHP Aspell DLL and the GNU Aspell version installed by Pidgin conflict and Pidgin crashes when starting.

Uninstalling GNU Aspell is required to be able to start Pidgin, which of course will not support spelling anymore.

Important note: the PHP directory is declared in my PATH environment variables.

FYI: on my Vista installation, pidgin.RPT was not in the specified %USERPROFILE% directory, it was in "C:\Program Files\Pidgin".

Attachments (1)

pidgin.RPT (5.7 KB) - added by BoneBreaker 9 years ago.
Crash report (RPT)

Download all attachments as: .zip

Change History (16)

Changed 9 years ago by BoneBreaker

Crash report (RPT)

comment:1 Changed 9 years ago by BoneBreaker

  • Description modified (diff)
  • Keywords PHP added; Apache removed
  • Summary changed from Apache/Aspell conflict causing crash on start up to PHP/Pidgin Aspell conflict causing crash on start up

comment:2 Changed 9 years ago by BoneBreaker

  • Description modified (diff)

comment:3 Changed 9 years ago by rekkanoryo

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

Closed as duplicate of #7750.

comment:4 follow-up: Changed 9 years ago by BoneBreaker

Sorry for the duplicate.

So I see 2 hacks involving either uninstalling apsell or renaming a .dll, but no real fix to the problem. If unsolved dll conflicts earn a "closed" status, I really wonder what bugs will remain open.

Is Pidgin the only OSS using Aspell? Certainly not. Is it the only one chocking on it? Well so far it is, and it seems it'll be so for some time.

Have a good time closing tickets.

comment:5 in reply to: ↑ 4 Changed 9 years ago by datallah

Replying to BoneBreaker:

So I see 2 hacks involving either uninstalling apsell or renaming a .dll, but no real fix to the problem. If unsolved dll conflicts earn a "closed" status, I really wonder what bugs will remain open.

Is Pidgin the only OSS using Aspell? Certainly not. Is it the only one chocking on it? Well so far it is, and it seems it'll be so for some time.

Have a good time closing tickets.

Did you actually look at #7750?

There is nothing we can do about this from our end if your php installation pollutes your system with a binary-incompatible aspell dll with the same name.

comment:6 Changed 9 years ago by BoneBreaker

Yes I did, that's where a user said renaming the php dll solved his problem.

What I'd consider to try fixing this problem:

  • if Pidgin installed GNU Aspell (probably the case for most Windows users), then I guess it should be able to actually *know* where to look for the right dll just installed.
  • if for some reason it can't fetch that variable, then check the dll version, if incorrect gracefully disable aspell with a warning message instead of crashing Pidgin.

comment:7 Changed 9 years ago by datallah

There are a number of issues with your assumptions.

Firstly, we just run an external installer, so we don't know where the version installed through our installer (if there is one) actually goes; we use a registry lookup to try to find the right Aspell path - the php installer appears to be rudely updating said registry key to point to their incompatible version.

The aspell dll doesn't contain versioning information (even if it did, the php version appears to be the same version based on the dll naming).

Sure, we could add some ugly hacks to try to recognize a specific binary and such, but the fundamental problem is that php is replacing the standard aspell dll with an incompatible one and screwing up the registry key.

Please file a ticket with the php distribution you're using.

comment:8 Changed 9 years ago by BoneBreaker

Actually I'm not using any installer for PHP, I download the zipped binary package, I have the official 5.2.8 version.

The only thing I'm doing that obviously ends up with this conflict is manually declaring the php directory (thus the path to the faulty dll) to the Vista environment variable PATH. I've no idea what the official php installer does, or what the numerous LAMP packages do, yet I'm 100% positive this php dll is nowhere else on my system.

comment:9 Changed 9 years ago by rekkanoryo

That is your problem. Windows looks in %PATH% for libraries before looking elsewhere.

comment:10 follow-up: Changed 9 years ago by datallah

Ok, then it is a problem with you including php in the system path; not doing that will prevent the problem from happening.

I realize that there are hacky workarounds that we could do for the case where both the standard aspell is installed and you have the broken version in your path, but the real problem is that the broken version with the same name exists (and when you put it in the path, it becomes a problem for anything expecting the real version).

This is a common windows DLL hell type of situation that we shouldn't try to work around via ugly hacks.

If the php folks recommend that you put the directory containing that dll in your PATH, then you should file a ticket asking them to rename the dll to avoid this "Dll Hell" type of situation.

comment:11 in reply to: ↑ 10 ; follow-up: Changed 9 years ago by BoneBreaker

Replying to datallah:

If the php folks recommend that you put the directory containing that dll in your PATH, then you should file a ticket asking them to rename the dll to avoid this "Dll Hell" type of situation.

They don't, however it's a convenient way to have a CLI available without having to manually cd to the executable path each time.

Thanks for taking the time to clear things a bit. I removed php from the %PATH%, and now all's back to its normal state. That still probably leaves some people with a crashing Pidgin. I use Pidgin and php for years and this problem is fairly new: since php 5.2.7 I believe, released on early December.

comment:12 in reply to: ↑ 11 Changed 9 years ago by datallah

Replying to BoneBreaker:

They don't, however it's a convenient way to have a CLI available without having to manually cd to the executable path each time.

If you google "AppPaths?", you'll see that there is a way you can create a path that is specific to a executable. This is frequently a good way to be able to run such things without adding them to your system path.

comment:13 Changed 9 years ago by rekkanoryo

Ticket #7950 has been marked as a duplicate of this ticket.

comment:14 Changed 8 years ago by datallah

Ticket #8329 has been marked as a duplicate of this ticket.

comment:15 Changed 8 years ago by datallah

Ticket #10332 has been marked as a duplicate of this ticket.

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!