Processing commands for cont...@bugs.debian.org:
> tags 592751 + pending
Bug #592751 [libgnustep-base1.20] Broken on hppa; programs abort with malloc
assertion failure
Added tag(s) pending.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
592751: http://bugs.debia
tags 592751 + pending
thanks
В 17:27 -0600 на 19.08.2010 (чт), dann frazier написа:
> With latest trunk:
> [good]
>
> If I revert back to r31185:
> [bad]
Wonderful, a New Hope for the GNUstep transition.
Many thanks to you all!
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.
On Fri, Aug 20, 2010 at 12:47:33AM +0300, Yavor Doganov wrote:
> Carlos O'Donell wrote:
> > On Thu, Aug 19, 2010 at 1:56 PM, Yavor Doganov wrote:
> > > Do you find anything disturbing in this approach, in particular:
> >
> > Yes, you don't take into account the alignment requirement of the
> > st
Carlos O'Donell wrote:
> On Thu, Aug 19, 2010 at 1:56 PM, Yavor Doganov wrote:
> > Do you find anything disturbing in this approach, in particular:
>
> Yes, you don't take into account the alignment requirement of the
> structure.
Thanks, that was really helpful.
Mehdi, could you please do `svn
On Thu, Aug 19, 2010 at 1:56 PM, Yavor Doganov wrote:
> Do you find anything disturbing in this approach, in particular:
Yes, you don't take into account the alignment requirement of the structure.
> --- Headers/Additions/GNUstepBase/GSConfig.h.in (revision 28611)
> +++ Headers/Additions/GNUstep
On 08/19/2010 07:56 PM, Yavor Doganov wrote:
>
> @GS_SIZEOF_COND_T@ and @GS_SIZEOF_MUTEX_T@ should be both 48 on hppa.
> (Mehdi/Dann, can you double check that by grepping GSConfig.h?)
>
Confirmed.
--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ
Carlos O'Donell wrote:
> Once we have a backtrace, either via a core dump, or attached gdb,
> then we can talk about the likely cause.
See the bug log -- there are lots of them, but none is really useful.
GNUstep Base uses NSLock extensively to protect critical parts of
code, so there's something
On Thu, Aug 19, 2010 at 01:28:30PM -0400, Carlos O'Donell wrote:
> On Thu, Aug 19, 2010 at 12:38 PM, dann frazier wrote:
> >> There *was* a vfork bug that was just fixed in glibc that could cause
> >> problems.
> >
> > Are you referring to this one?
> >
> > * Add patches/hppa/cvs-vfork.diff to f
On Thu, Aug 19, 2010 at 12:38 PM, dann frazier wrote:
>> There *was* a vfork bug that was just fixed in glibc that could cause
>> problems.
>
> Are you referring to this one?
>
> * Add patches/hppa/cvs-vfork.diff to fix stack frame creating during
> vfork in multithreaded environments.
>
> fw
On Thu, Aug 19, 2010 at 11:55:40AM -0400, Carlos O'Donell wrote:
> On Thu, Aug 19, 2010 at 11:00 AM, Mehdi Dogguy wrote:
> > On 19/08/2010 16:29, Yavor Doganov wrote:
> >> ?? 16:15 +0200 19.08.2010 (), Mehdi Dogguy :
> >>> On 19/08/2010 15:45, Yavor Doganov wrote:
> Thank
Carlos O'Donell wrote:
> Does this code use vfork?
The library uses vfork only in the NSTask class, which means that any
code using -[NSTask launch] uses vfork indirectly. The gdnc daemon is
one such program, but this is never reached with `gdnc --help'. All
the other test programs that were tri
On 19/08/2010 17:55, Carlos O'Donell wrote:
> On Thu, Aug 19, 2010 at 11:00 AM, Mehdi Dogguy
> wrote:
>> On 19/08/2010 16:29, Yavor Doganov wrote:
>>> В 16:15 +0200 на 19.08.2010 (чт), Mehdi Dogguy написа:
On 19/08/2010 15:45, Yavor Doganov wrote:
> Thanks, informing upstream. Can you na
On Thu, Aug 19, 2010 at 11:00 AM, Mehdi Dogguy wrote:
> On 19/08/2010 16:29, Yavor Doganov wrote:
>> В 16:15 +0200 на 19.08.2010 (чт), Mehdi Dogguy написа:
>>> On 19/08/2010 15:45, Yavor Doganov wrote:
Thanks, informing upstream. Can you narrow it down a bit more?
>>>
>>> I narrowed it down
On 19/08/2010 10:59, Yavor Doganov wrote:
> Please start from the tip, just in case the issue is gone accidentally
> (that would be a miracle, but well, who knows). Then skip directly to
> the last known "bad" revision 30325 (that's 1.20.0, which you already
> confirmed has the problem). The last
В 16:15 +0200 на 19.08.2010 (чт), Mehdi Dogguy написа:
> On 19/08/2010 15:45, Yavor Doganov wrote:
> > Thanks, informing upstream. Can you narrow it down a bit more?
>
> I narrowed it down to r28600:r28625.
That's mostly the NSThread/NSLock redesign. Too bad, one of the
trickiest places...
> I
On 19/08/2010 16:29, Yavor Doganov wrote:
> В 16:15 +0200 на 19.08.2010 (чт), Mehdi Dogguy написа:
>> On 19/08/2010 15:45, Yavor Doganov wrote:
>>> Thanks, informing upstream. Can you narrow it down a bit more?
>>
>> I narrowed it down to r28600:r28625.
>
It's even r28610:r28615.
--
Mehdi Dog
On Thu, Aug 19, 2010 at 03:29:08PM +0200, Mehdi Dogguy wrote:
> On 19/08/2010 10:59, Yavor Doganov wrote:
> >
> > Please start from the tip, just in case the issue is gone accidentally
> > (that would be a miracle, but well, who knows). Then skip directly to
> > the last known "bad" revision 3032
On 19/08/2010 15:45, Yavor Doganov wrote:
> В 15:29 +0200 на 19.08.2010 (чт), Mehdi Dogguy написа:
>> I tested on paer. r28700 failed and r28600 worked
>
> Thanks, informing upstream. Can you narrow it down a bit more?
>
I narrowed it down to r28600:r28625. I'm still trying to see which commit
В 15:29 +0200 на 19.08.2010 (чт), Mehdi Dogguy написа:
> I tested on paer. r28700 failed and r28600 worked
Thanks, informing upstream. Can you narrow it down a bit more? Are the
revisions in between non-buildable?
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a sub
On 19/08/2010 10:59, Yavor Doganov wrote:
>
> Please start from the tip, just in case the issue is gone accidentally
> (that would be a miracle, but well, who knows). Then skip directly to
> the last known "bad" revision 30325 (that's 1.20.0, which you already
> confirmed has the problem). The l
On 19/08/2010 10:59, Yavor Doganov wrote:
> Please start from the tip, just in case the issue is gone accidentally
> (that would be a miracle, but well, who knows).
trunk doesn't fix the problem, fwiw.
Regards,
--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/
--
To UNSUBSCRIBE, email to debian-
On Wed, Aug 18, 2010 at 12:50:39PM -0600, dann frazier wrote:
> _gnu_process_args (argc=1, argv=0x3cb98, env=0x3bd08) at NSProcessInfo.m:233
> 233 NSProcessInfo.m: No such file or directory.
> in NSProcessInfo.m
> 238 in NSProcessInfo.m
> 240 in NSProcessInfo.m
> *__GI_strlen (str=0xfaf
On Wed, Aug 18, 2010 at 06:42:38PM +0300, Yavor Doganov wrote:
> dann frazier wrote:
> > Attached - though I don't really get anything from the stepping:
>
> Hmm, there seems to be some misunderstanding (probably because of the
> confusingly identically named test.m files) -- perform the stepping
dann frazier wrote:
> Attached - though I don't really get anything from the stepping:
Hmm, there seems to be some misunderstanding (probably because of the
confusingly identically named test.m files) -- perform the stepping
with the test.m file I sent you earlier:
> > (http://bugs.debian.org/cgi
On Wed, Aug 18, 2010 at 12:12:26PM +0300, Yavor Doganov wrote:
> ?? 14:17 -0600 17.08.2010 (), dann frazier :
> > (sid)da...@paer:~$ ./obj/test
> > Test
>
> Good. Please run another test program... If it works, which I hope and
> expect so, then the culprit is really NSProc
В 14:17 -0600 на 17.08.2010 (вт), dann frazier написа:
> (sid)da...@paer:~$ ./obj/test
> Test
Good. Please run another test program... If it works, which I hope and
expect so, then the culprit is really NSProcessInfo. In the backtraces
you sent initially, frame #14 is an impossible code path,
On Tue, Aug 17, 2010 at 02:16:46PM -0600, dann frazier wrote:
> We should be able to automate the bisection (if we can rely on each
> version being buildable..) If you can point me to the source.. and it
> is in git (or an svn repo I can use w/ git-svn) I can do that pretty
> easily I think.
It's
On Tue, Aug 17, 2010 at 10:54:50PM +0300, Yavor Doganov wrote:
> Meanwhile, can you additionally test the attached program, which doesn't
> use NSProcessInfo (upstream has some suspicions that's the class where
> the bug is)? You can reuse the same GNUmakefile I sent you earlier.
> #import
>
On Tue, Aug 17, 2010 at 10:12:01PM +0300, Yavor Doganov wrote:
> On Tue, Aug 17, 2010 at 12:59:15PM -0600, dann frazier wrote:
> > (sid)da...@paer:~/test-0.1$ ./test
> > Test 1
> > Test 2
> > Test 3
>
> Thanks. Do you get something different if you rebuild with
>
> make OBJCFLAGS="-fexceptions
Meanwhile, can you additionally test the attached program, which doesn't
use NSProcessInfo (upstream has some suspicions that's the class where
the bug is)? You can reuse the same GNUmakefile I sent you earlier.
#import
int
main (void)
{
CREATE_AUTORELEASE_POOL (pool);
NSString *foo = @"Te
On Tue, Aug 17, 2010 at 12:59:15PM -0600, dann frazier wrote:
> (sid)da...@paer:~/test-0.1$ ./test
> Test 1
> Test 2
> Test 3
Thanks. Do you get something different if you rebuild with
make OBJCFLAGS="-fexceptions -fobjc-exceptions -fgnu-runtime"
? (I doubt it.)
Before starting the masochis
On Tue, Aug 17, 2010 at 07:56:04PM +0300, Yavor Doganov wrote:
> dann frazier wrote:
> > Oh, duh.. overlooked that file thinking it was a directory - sorry :)
>
> No problem.
>
> > test: malloc.c:3097: sYSMALLOc: Assertion ...
>
> Thanks, that's seriously broken (expected). What happens if you
On Tue, Aug 17, 2010 at 07:03:03PM +0300, Yavor Doganov wrote:
> On Tue, Aug 17, 2010 at 09:57:55AM -0600, dann frazier wrote:
> > ur.. how do I run it?
>
> ./obj/test
Oh, duh.. overlooked that file thinking it was a directory - sorry :)
(sid)da...@paer:~$ ./obj/test
test: malloc.c:3097: sYSMALL
On Tue, Aug 17, 2010 at 09:57:55AM -0600, dann frazier wrote:
> ur.. how do I run it?
./obj/test
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Tue, Aug 17, 2010 at 02:25:35PM +0300, Yavor Doganov wrote:
> ?? 21:18 +0300 16.08.2010 (), Yavor Doganov :
> > As I can't reproduce the nefarious behavior on gcc61.fsffrance.org
> > with a manually built GCC 4.4.4 from pristine source, I'm now building
> > a new gcc with De
В 21:18 +0300 на 16.08.2010 (пн), Yavor Doganov написа:
> As I can't reproduce the nefarious behavior on gcc61.fsffrance.org
> with a manually built GCC 4.4.4 from pristine source, I'm now building
> a new gcc with Debian patches.
Still can't reproduce with it :-(
Can you compile and run this sim
On Mon, Aug 16, 2010 at 09:18:51PM +0300, Yavor Doganov wrote:
> dann frazier wrote:
> > Same thing:
>
> OK. Another try with 1.20.0 this time?
> (http://snapshot.debian.org/archive/debian/20100524T154820Z/pool/main/g/gnustep-base/gnustep-base_1.20.0-1.dsc)
locally built 1.20.0:
r...@c3700:/tmp
dann frazier wrote:
> Same thing:
OK. Another try with 1.20.0 this time?
(http://snapshot.debian.org/archive/debian/20100524T154820Z/pool/main/g/gnustep-base/gnustep-base_1.20.0-1.dsc)
Upstream thinks this is either a GCC/libobjc issue exposed by the new
-base code, or a serious problem in gnust
Hi Dann,
В 22:21 -0600 на 12.08.2010 (чт), dann frazier написа:
> r...@c3700:/tmp/gnustep-base-1.19.3# gdnc --help
Could you perform the same test with a manually built
gnustep-base/1.20.1-2, on the same machine? It might be possible that
the package was somehow miscompiled by the official build
On Mon, Aug 16, 2010 at 05:47:11PM +0300, Yavor Doganov wrote:
> Hi Dann,
>
> ?? 22:21 -0600 12.08.2010 (), dann frazier :
> > r...@c3700:/tmp/gnustep-base-1.19.3# gdnc --help
>
> Could you perform the same test with a manually built
> gnustep-base/1.20.1-2, on the same machi
40 matches
Mail list logo
