Opened 11 years ago

Closed 10 years ago

#7608 closed patch (fixed)

Exception when calling open/read/close with a negative file descriptor on Windows (with MS CRT)

Reported by: fqueze Owned by: datallah
Milestone: 2.5.3 Component: libpurple
Version: 2.5.2 Keywords:


When I compile libpurple with MSVC8 (Visual Studio 2005) and the MS CRT, I get exceptions (similar to crashes from a user point of view) in wpurple_read/write/close.

These exceptions are thrown when these functions are called with a negative file descriptor. libpurple sometimes does this when a file descriptor has been closed: it is replaced by the -1 value in the structure where the fd value was stored (happens at least with the xmpp and oscar prpls).

On UNIX, calling these system calls with bad file descriptor values puts the EBADF value in errno. I think we should just do the same on Windows.

Attachments (1)

fix-exceptions-with-MS-CRT.patch (1.2 KB) - added by fqueze 11 years ago.

Download all attachments as: .zip

Change History (5)

Changed 11 years ago by fqueze

comment:1 Changed 10 years ago by datallah

I guess I'm not necessarily opposed to this in principle, but ideally the places that try to use the bogus fds should be fixed - this type of guard shouldn't be necessary.

comment:2 Changed 10 years ago by fqueze

Yes, the places that use bogus fds should be fixed, they are actual bugs. But some can be in plugins so I think we really need to fix it here too, and prevent the 'crashes'.

comment:3 Changed 10 years ago by rekkanoryo

  • Owner set to datallah

comment:4 Changed 10 years ago by datallah@…

  • Milestone set to 2.5.3
  • Resolution set to fixed
  • Status changed from new to closed

(In c1d44992f600877e08d67a35323d16fcacff92de):
(Slightly modified) patch from fqueze to avoid exceptions with newer win32 CRTs. I modified it to use g_return_val_if_reached() because we need to track down and fix the places where invalid fds are being used. Fixes #7608

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!