[Fwd: Bug#225154: gnustep-base1-dbg: unability to debug or even launch app]

-----Forwarded Message from debian bug tracking system-----
Please, preserve the CC to nnn-forwarded <at> bugs when you reply, so that
the bug tracking system will file your reply with the original report.

From: Wolfgang Sourdeau <wolfgang <at> contre.com>
To: Debian Bug Tracking System <submit <at> bugs.debian.org>
Subject: Bug#225154: gnustep-base1-dbg: unability to debug or even launch app
Date: Fri, 26 Dec 2003 18:57:08 -0500

Package: gnustep-base1-dbg
Version: 1.9.0-2
Severity: normal

Hello,

This problem seems to have appeared recently. Whenever I try to build my
project with "make debug=yes", I can't even launch it, which prevents me
from using gdb. The error message that is displayed is:

(gdb) run
Starting program: /home/wolfgang/programmes/gnustep/Cynthiune/Cynthiune.debug/Cynthiune
[New Thread 16384 (LWP 15443)]

GNUSTEP Internal Error:
The private GNUstep function to establish the argv and environment
variables was not called.
Please report the error to bug-gnustep <at> gnu.org.

/home/wolfgang/programmes/gnustep/Cynthiune/Cynthiune.debug/Cynthiune: Uncaught
exception NSInternalInconsistencyException, reason:

GSMime tries to use NSString:s as c strings

While looking through the audit patches, I noticed a probable bug in
GSMime. The attached patch should fix it, but I don't use the code and I
have no way of testing the conditions that are involved.

- Alexander Malmberg

Index: Source/Additions/GSMime.m
===================================================================
RCS file: /cvsroot/gnustep/gnustep/core/base/Source/Additions/GSMime.m,v
retrieving revision 1.87
diff -u -r1.87 GSMime.m
--- Source/Additions/GSMime.m	5 Jan 2004 18:28:18 -0000	1.87
+++ Source/Additions/GSMime.m	8 Jan 2004 00:52:40 -0000
 <at>  <at>  -1245,7 +1245,7  <at>  <at> 

       if (flags.wantEndOfLine == 1)
 	{
-	  result = [self parse: [NSData dataWithBytes:  <at> "\r\n" length: 2]];
+	  result = [self parse: [NSData dataWithBytes: "\r\n" length: 2]];
 	}
       else if (flags.inBody == 1)
 	{
 <at>  <at>  -1257,7 +1257,7  <at>  <at> 
 	   * If still parsing headers, add CR-LF sequences to terminate
 	   * the headers.
            */
-	  result = [self parse: [NSData dataWithBytes:  <at> "\r\n\r\n" length: 4]];
+	  result = [self parse: [NSData dataWithBytes: "\r\n\r\n" length: 4]];
 	}
       flags.wantEndOfLine = 0;

Re: GSMime tries to use NSString:s as c strings

On 8 Jan 2004, at 00:56, Alexander Malmberg wrote:

> While looking through the audit patches, I noticed a probable bug in
> GSMime. The attached patch should fix it, but I don't use the code and 
> I
> have no way of testing the conditions that are involved.

Thanks ... Applied that.
The code was only used to try to succeed in parsing slightly corrupt 
mime
(missing a few trailing characters) ... so never encountered when 
getting
mail from good sources ... but explains a few failures I've had dealing 
with
poor mime data.

Again - Unable to compile gnustep-baseadd with apple-apple-apple

I got no reply to that mail, and no modification was done in the 
repository, so I post it once again.

Stéphane

Begin forwarded message:

> From: Stéphane Corthésy <stephane <at> sente.ch>
> Date: December 27, 2003 6:37:50 PM CET
> To: bug-gnustep <at> gnu.org
> Subject: Unable to compile gnustep-baseadd with apple-apple-apple
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> X-Mailer: Apple Mail (2.609)
>
> Hi,
>
> I tried to compile gnustep base, from CVS sources, on Darwin, using 
> apple-apple-apple combo, but failed to (I installed gnustep-make 
> before and did the compilation using gnustep native system, not MacOSX 
> files).
>
> There are two main problems: linker is unable to link gnustep-baseadd, 
> due to a problem with libxml2,
>
>  Linking library libgnustep-baseadd ...
> ld: Additions/./shared_obj/subproject.o illegal reference to symbol: 
> _getColumnNumber defined in indirectly referenced dynamic library 
> /usr/lib/libxml2.2.dylib
> /usr/bin/libtool: internal link edit command failed
>

NSMenu menu position saving bug (PATCH)

Hi there,

The menu position saving code has not worked for me for quite awhile. 
After being prodded by Alex I chased this bug down. Attached is a 
patch. Basically the problem is with this code:

return [NSString stringWithFormat:  <at> "\033% <at> ", [self title]]; 
//NSMenu.m ~155

On my machine this would return, for the Info menu, "nfo" not 
"\033Info", so the key was always nil (interestingly enough, if I 
manually edited the key in the defaults to be \033Info it worked 
properly). I changed this to:

return [NSString stringWithFormat:  <at> "+% <at> ", [self title]];

and the key was saved and read correctly.

I'm not sure if this is the proper fix, but it works here.

Cheers,

Michael

<nsmenu-bug.patch>

_______________________________________________
Bug-gnustep mailing list

NSCell -_nonAutoreleasedTypingAttributes minor change.

Hi,

Seemingly the baseline for string drawing in controls is one pixel too 
low. Maybe I'm seeing things, but this small patch for NSCell makes 
these strings center a little better. Some extra research might be 
necessary.

Cheers,

Michael

<nscell-prettytext.patch>

_______________________________________________
Bug-gnustep mailing list
Bug-gnustep <at> gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnustep

Re: NSMenu menu position saving bug (PATCH)

On 10 Jan 2004, at 15:13, Michael Hanni wrote:

> Hi there,
>
> The menu position saving code has not worked for me for quite awhile. 
> After being prodded by Alex I chased this bug down. Attached is a 
> patch. Basically the problem is with this code:
>
> return [NSString stringWithFormat:  <at> "\033% <at> ", [self title]]; 
> //NSMenu.m ~155
>
> On my machine this would return, for the Info menu, "nfo" not 
> "\033Info",

Are you sure? On most systems just printing this string to a terminal 
will look like 'nfo' because the terminal driver will take the leading 
escape character to mean that the next character should not be 
displayed.  Try printing to a file then editing/viewing that file with 
a program which displays control characters.

>  so the key was always nil (interestingly enough, if I manually edited 
> the key in the defaults to be \033Info it worked properly). I changed 
> this to:

So it sounds like the escape character was not saved into the defaults 
... either a problem with the escape in the string, or a problem with 
converting it back to the four character sequence ('\\', '0', '3', '3') 
it should be coded as in the defaults database.

Re: NSMenu menu position saving bug (PATCH)

Hi,

On 2004-01-10 01:59:05 -0700 Richard Frith-Macdonald 
<richard <at> brainstorm.co.uk> wrote:

> On 10 Jan 2004, at 15:13, Michael Hanni wrote:
>> 
>> so the key was always nil (interestingly enough, if I manually 
>> edited the 
>> key in the defaults to be \033Info it worked properly). I changed 
>> this to:
> 
> So it sounds like the escape character was not saved into the 
> defaults ... 
> either a problem with the escape in the string, or a problem with 
> converting 
> it back to the four character sequence ('\\', '0', '3', '3') it 
> should be 
> coded as in the defaults database.

If I change this to \\033 instead of \033 it works ok... Is it that 
when you give \033Info to NSString in a cstring it tries to come up 
with a character with value 033I?

With the current code, minus my modification, my defaults are always 
this:

         NSMenuLocations = {
             "\000" = "136 379 77 233 0 0  960 768 ";
             "\000Edit" = "626 325 79 128 0 0  960 768 ";

Re: NSMenu menu position saving bug (PATCH)

On 10 Jan 2004, at 16:23, Michael Hanni wrote:

> Hi,
>
> On 2004-01-10 01:59:05 -0700 Richard Frith-Macdonald 
> <richard <at> brainstorm.co.uk> wrote:
>
>> On 10 Jan 2004, at 15:13, Michael Hanni wrote:
>>> so the key was always nil (interestingly enough, if I manually 
>>> edited the key in the defaults to be \033Info it worked properly). I 
>>> changed this to:
>> So it sounds like the escape character was not saved into the 
>> defaults ... either a problem with the escape in the string, or a 
>> problem with converting it back to the four character sequence ('\\', 
>> '0', '3', '3') it should be coded as in the defaults database.
>
> If I change this to \\033 instead of \033 it works ok... Is it that 
> when you give \033Info to NSString in a cstring it tries to come up 
> with a character with value 033I?

When given a string literal ' <at> "\033% <at> "' in the source code, the 
Objective-C compiler (gcc) produces an NSConstantString object pointing 
to a four byte sequence - escape, percent, at, nul

At runtime, the GSFormat() function should initialise an NSString from 
this to contain 5 unicode characters - escape, I, n, f, o

When storing the key into the defaults database, the PString() function 
should convert this to 8 ascii characters - backslash, 0, 3, 3, I, n, 

Re: NSMenu menu position saving bug (PATCH)

On 10 Jan 2004, at 09:52, Richard Frith-Macdonald wrote:

>>
>> This is on a powerpc machine, debian linux, gcc 3.3.3-0pre1, and 
>> libc6 2.3.2.ds1-10.
>>
>> Any ideas?
>
> Just one ... I think powerpc systems use a different byte order from 
> intel systems ...
> maybe there is some problem with accessing the wrong byte of the 
> 16-bit unicode characters.
> I'll look and see if I can spot anything in the source.

I think I have found the problem.  I've committed a fix for the base 
library to cvs.
Please could you update and see if it works for you.