Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#6399 closed defect (fixed)

procedure entry point GetGuiResources could not be located

Reported by: tmetro Owned by: datallah
Milestone: 2.5.0 Component: winpidgin (gtk)
Version: 2.4.2 Keywords:
Cc:

Description (last modified by rekkanoryo)

On startup of Pidgin (2.4.2 and earlier) on a Windows NT system I see a dialog:

WinpidginMsgWin: pidgin.exe - Entry Point Not Found

The procedure entry point GetGuiResources could not be located in the dynamic link library USER32.dll.

I've been seeing this for years, and I might even have reported it before in the Sourceforge tracker. It appears to be benign, as Pidgin seems to otherwise function after the dialog is dismissed.

Attachments (2)

debug-pre_error.log (4.6 KB) - added by tmetro 11 years ago.
Debug log up to appearance of error dialog
debug-post_error.log (7.5 KB) - added by tmetro 11 years ago.
Debug log after error dialog

Download all attachments as: .zip

Change History (8)

comment:1 Changed 11 years ago by rekkanoryo

  • Component changed from pidgin (gtk) to winpidgin (gtk)
  • Description modified (diff)
  • Owner set to datallah

From the message and the fact that you're using NT 4.0, it looks as though we're (possibly indirectly) calling a function from the Win32 API that is present only in Windows 2000 or newer.

comment:2 follow-up: Changed 11 years ago by datallah

  • pending changed from 0 to 1

People still use NT4?!

This isn't something we're doing directly - it isn't even something that is done by Glib, GTK+, Pango or Cairo, so I don't know where it is coming from.

The fact that it works after you dismiss the dialog indicates that it is withing something that is being dynamically loaded, perhaps a plugin of some sort.

If you get a debug log up to the time that the dialog appears, that might help track down where it is occurring.

Changed 11 years ago by tmetro

Debug log up to appearance of error dialog

Changed 11 years ago by tmetro

Debug log after error dialog

comment:3 in reply to: ↑ 2 ; follow-up: Changed 11 years ago by tmetro

  • pending changed from 1 to 0

Replying to datallah:

People still use NT4?!

Amazing, isn't it? :-)

...perhaps a plugin of some sort.

Certainly could be. I'm currently loading:

Buddy State Notification
Hide Conversation
History
I'dle Mak'er
IRC Helper
IRC More
Message Notification
Message Timestamp
Off-the Record Messaging
Offline Message Emulation
Pidgin GTK+ Theme Control
Psychic Mode
Release Notification
Windows Pidgin Options

This isn't something we're doing directly...

So you're saying a grep of the main source for GetGuiResources doesn't turn up anything?

If you get a debug log up to the time that the dialog appears...

Attached.

The last few lines logged up to the point where the dialog appears are:

(19:22:31) plugins: probing C:\bin\net\misc\Pidgin\plugins\libsametime.dll
(19:22:32) plugins: C:\bin\net\misc\Pidgin\plugins\libsametime.dll has a prefs_info, but is a prpl. This is no longer supported.
(19:22:32) plugins: probing C:\bin\net\misc\Pidgin\plugins\libsimple.dll
(19:22:32) plugins: probing C:\bin\net\misc\Pidgin\plugins\libxmpp.dll

I'm guessing that while the Jabber protocol plugin (libxmpp.dll) is a good candidate, that debug log buffering and and/or multiple threads might mean the cause isn't so obvious.

I've also attached the remainder of the log post-dialog, and the very next line logged is:

(19:22:53) util: Reading file xmpp-caps.xml from directory C:\WINNT\Profiles\Administrator\Application Data\.purple

...which doesn't seem all that notable.

It appears the plugins are probed prior to the error, but not loaded until after the dialog appears.

comment:4 in reply to: ↑ 3 ; follow-up: Changed 11 years ago by datallah

  • Status changed from new to assigned

Replying to tmetro:

So you're saying a grep of the main source for GetGuiResources doesn't turn up anything?

Exactly. That also eliminates any of the plugins that are included in the default installation.

The last few lines logged up to the point where the dialog appears are:

<snip>

(19:22:32) plugins: probing C:\bin\net\misc\Pidgin\plugins\libxmpp.dll

<snip>

I'm guessing that while the Jabber protocol plugin (libxmpp.dll) is a good candidate, that debug log buffering and and/or multiple threads might mean the cause isn't so obvious.

Hmm... it certainly isn't anything in the XMPP prpl plugin directly. Pidgin is (with a couple specific exceptions) single-threaded, so hopefully this isn't an issue.

It appears the plugins are probed prior to the error, but not loaded until after the dialog appears.

This tells us that it is something that happens during the initialization of the xmpp prpl. In turn, this leads to CyrusSASL and eventually to the GSSAPI plugin and then the MIT Kerberos library, where we find the culprit.

You can avoid this issue by deleting the saslGSSAPI.dll from the ...\Pidgin\sasl2 directory - it will have no negative effects since it can't load anyway (it is used for authenticating with your Windows Credentials for servers that support such a mechanism).

I'll update the installer to automatically remove the file on NT4.

comment:5 Changed 11 years ago by datallah@…

  • Milestone set to 2.5.0
  • Resolution set to fixed
  • Status changed from assigned to closed

(In 812f25c342b8238ecd22b32c9a3396db3efcb329):
Don't install the GSSAPI SASL plugin on NT4 as it isn't compatible. Fixes #6399.

comment:6 in reply to: ↑ 4 Changed 11 years ago by tmetro

Replying to datallah:

You can avoid this issue by deleting the saslGSSAPI.dll...

Confirmed. Thanks for the quick follow-up.

I'll update the installer to automatically remove the file on NT4.

Sounds good. Now if I can just get 2.4.3 to start without crashing (see ticket #6398), I'll be all set.

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!