[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #9, bug #30766 (project gnustep):

FYI: I asked the original bug reporter to try 1.20.0; it still fails in the
same way.

I'll wait for my tests with a debianized gcc before doing anything else.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #8, bug #30766 (project gnustep):

>> Base 1.19.3 runs fine, so I guess they can be ruled out right
>> away.

> Unfortunately not as it's perfectly possible for some code to 
> trigger bugs in the compiler or runtime that other code does
> not trigger.

Right, I was thinking along the same line as well right after I sent the
message.  Today I got an account on the GCC compile farm
(http://gcc.gnu.org/wiki/CompileFarm) and could not reproduce the problem on
gcc61.fsffrance.org with Base 1.20.1, compiled with manually built GCC 4.4.4. 
I'm now building the same version of GCC + Debian-specific patches; if it
exposes the problem, I'll pass the hot potato to the Debian GCC maintainers. 
But we'll still need some workaround to get functional GNUstep on this
architecture.

> My only new idea on how to proceed is to try a bisection
> of the code changes since 1.19.3.

Yes, I was going to do exactly this if I was fortunate enough to reproduce.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Fred Kiefer]

Follow-up Comment #7, bug #30766 (project gnustep):

Thank you for the reference to the build output. 

My only new idea on how to proceed is to try a bisection of the code changes
since 1.19.3. You should start of by testing 1.20.0 and then use SVN versions
of the code in between.

We have too much that changed since 1.19.3 to tell otherwise. The whole
thread and lock handling was completely rewritten, the interaction with the
Objective-C runtime was reimplemented, so were NSInvocation and NSNumber. We
enabled 64 bit NSInteger support and so much more.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Richard Frith-Macdonald]

Follow-up Comment #6, bug #30766 (project gnustep):

>> The later two could be ruled out by running a non GNUstep 
>> Objective-C program compile don this machine. 
>
> Base 1.19.3 runs fine, so I guess they can be ruled out right away. 

Unfortunately not as it's perfectly possible for some code to trigger bugs in
the compiler or runtime that other code does not trigger.

>> Next you should check which of the different cases for argument 
>> inspection applies in your environment. 
>
>I don't have access to Debian's porter machines, but I can ask the bug
reporter to >perform whatever tests are needed. 

I would guess that, in the absence of something like valgrind which will
report memory problems, what's needed is actually to run the program under gdb
and step through to find where something goes wrong.

One thing ... in the original stackdump reported I see this:

> #14 0x409e5304 in pathSeps () at NSString.m:268

but line 268 should only be executed if using mswindows style path separators
... which suggests that memory must already have been corrupted by the time
this point was reached.



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #5, bug #30766 (project gnustep):

Here is some information about this architecture, in case it can be of help.

Type size:
short 2
int   4 
long  4
long long 8
float 4
double8
long double   8
data pointer  4

endianness: big
unaligned access not OK
char signedness: s
stack grows up (the only platform where this is so)

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #4, bug #30766 (project gnustep):

> The later two could be ruled out by running a non GNUstep 
> Objective-C program compile don this machine.

Base 1.19.3 runs fine, so I guess they can be ruled out right away.

> Next you should check which of the different cases for argument
> inspection applies in your environment.

I don't have access to Debian's porter machines, but I can ask the bug
reporter to perform whatever tests are needed.

> Do you get any compiler warnings for GNUstep base?

Yes, many, particularly "cast increases required alignment of target type". 
See attached file warnings.txt; full build log available at
https://buildd.debian.org/fetch.cgi?pkg=gnustep-base&arch=hppa&ver=1.20.1-2&stamp=1281448914&file=log&as=raw.

(file #21236)
___

Additional Item Attachment:

File name: warnings.txt   Size:18 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Fred Kiefer]

Follow-up Comment #3, bug #30766 (project gnustep):

Not having valgrind is really bad.
The next thing that you could try to do is pin down where the problem comes
from. I think it can only be one of three things, either GNUstep base has some
serious problem (Most likely in NSProcessInfo where we try to gather the
process arguments), in the libobjc or in the compiler itself. 
The later two could be ruled out by running a non GNUstep Objective-C program
compile don this machine. 
Next you should check which of the different cases for argument inspection
applies in your environment.
There is one more point: Do you get any compiler warnings for GNUstep base?
If so, please report them here.


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30172] Converting strings lossy results to different strings than on OS X

[Fred Kiefer]

Follow-up Comment #6, bug #30172 (project gnustep):

GNUstep is doing the lossy conversion by using the translit flag of iconv.
The documentation for iconv states:
"When the string "//TRANSLIT" is appended to tocode, transliteration is
activated. This means that when a character cannot be represented in the
target character set, it can be approximated through one or several characters
that look similar to the original character."
This sounds just like the thing we want to do. And your example shows that
this conversion is really eager to provide the best possible transliteration.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep