[patch] Crash on windows hosts

[patch] Crash on windows hosts

[Paul Brook]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

serial_fdopen can return NULL on non-unix (ie. windows) hosts. This was 
causing a segfault in print_flush.
The attached patch fixes this.

Ok?

Paul

2005-04-28  Paul Brook  <paul@codesourcery.com>

	* exceptions.c (print_flush): Handle NULL gdb_stdout_serial.

[-- Attachment #2: patch.gdb_serflush --]
[-- Type: text/x-diff, Size: 677 bytes --]

Index: gdb/exceptions.c
===================================================================
RCS file: /var/cvsroot/src-cvs/src/gdb/exceptions.c,v
retrieving revision 1.19
diff -u -p -r1.19 exceptions.c
--- gdb/exceptions.c	11 Feb 2005 18:13:49 -0000	1.19
+++ gdb/exceptions.c	28 Apr 2005 01:23:04 -0000
@@ -282,8 +282,11 @@ print_flush (void)
 
   /* 3.  The system-level buffer.  */
   gdb_stdout_serial = serial_fdopen (1);
-  serial_drain_output (gdb_stdout_serial);
-  serial_un_fdopen (gdb_stdout_serial);
+  if (gdb_stdout_serial)
+    {
+      serial_drain_output (gdb_stdout_serial);
+      serial_un_fdopen (gdb_stdout_serial);
+    }
 
   annotate_error_begin ();
 }

Re: [patch] Crash on windows hosts

[Daniel Jacobowitz]

On Thu, Apr 28, 2005 at 03:00:34AM +0100, Paul Brook wrote:
> serial_fdopen can return NULL on non-unix (ie. windows) hosts. This was 
> causing a segfault in print_flush.
> The attached patch fixes this.
> 
> Ok?
> 
> Paul
> 
> 2005-04-28  Paul Brook  <paul@codesourcery.com>
> 
> 	* exceptions.c (print_flush): Handle NULL gdb_stdout_serial.

Hmm, this is probably OK... yeah, should be safe.  Give it a day in
case anyone who knows more about Windows than I do wants to object.  I
can't think of any reason to do this; we've already called the stdio
flush routines.  At worst it'll be cosmetic.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [patch] Crash on windows hosts

[Christopher Faylor]

On Wed, Apr 27, 2005 at 11:27:21PM -0400, Daniel Jacobowitz wrote:
>On Thu, Apr 28, 2005 at 03:00:34AM +0100, Paul Brook wrote:
>> serial_fdopen can return NULL on non-unix (ie. windows) hosts. This was 
>> causing a segfault in print_flush.
>> The attached patch fixes this.
>> 
>> Ok?
>> 
>> Paul
>> 
>> 2005-04-28  Paul Brook  <paul@codesourcery.com>
>> 
>> 	* exceptions.c (print_flush): Handle NULL gdb_stdout_serial.
>
>Hmm, this is probably OK... yeah, should be safe.  Give it a day in
>case anyone who knows more about Windows than I do wants to object.  I
>can't think of any reason to do this; we've already called the stdio
>flush routines.  At worst it'll be cosmetic.

I didn't look closely to see why Windows would return a NULL when other
systems would not but given that it is obviously possible for
serial_fdopen to return NULL, it seems like this patch is correct.

So, I'd agree with Daniel that it should be checked in.

cgf

Re: [patch] Crash on windows hosts

[Daniel Jacobowitz]

On Wed, Apr 27, 2005 at 11:36:12PM -0400, Christopher Faylor wrote:
> I didn't look closely to see why Windows would return a NULL when other
> systems would not but given that it is obviously possible for
> serial_fdopen to return NULL, it seems like this patch is correct.

I presume the reason is because there's no serial port named
"hardwire" on Windows - only Unix-like systems and GO32 (DOS).

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [patch] Crash on windows hosts

[Christopher Faylor]

On Thu, Apr 28, 2005 at 09:21:49AM -0400, Daniel Jacobowitz wrote:
>On Wed, Apr 27, 2005 at 11:36:12PM -0400, Christopher Faylor wrote:
>> I didn't look closely to see why Windows would return a NULL when other
>> systems would not but given that it is obviously possible for
>> serial_fdopen to return NULL, it seems like this patch is correct.
>
>I presume the reason is because there's no serial port named
>"hardwire" on Windows - only Unix-like systems and GO32 (DOS).

So, that points out a generic problem lurking behind this one.  The
Windows part of gdb should implement a "hardwire" serial port.  I guess
I'll put that on my todo list.

Btw, there is one other use of serial_fdopen which uses NULL protection
so, again, I'd say this is a trivial fix which should be checked in.

cgf