On 23/07/2020 16:05, Chris Johns wrote:
> I'd better get compiling.
>
> However, if I build it again the new libs I assume it won't work with
> the older ones?
In theory, we might get away with it, but only if I change
__pthread_cond again. The original one was:
struct __pthread_cond
{
/* Linked list of threads that are blocked on this condition var. */
struct __pthread_thread *waiting;
};
and the new one:
struct __pthread_cond
{
/* Absolute (CLOCK_REALTIME) or relative (CLOCK_MONOTONIC) clock? */
clockid_t clock_id;
/* Linked list of threads that are blocked on this condition var. */
struct __pthread_thread *waiting;
};
In hind sight, I should have placed "clock_id" *after* "waiting". The
code in python is attempting to access "waiting", but getting "clock_id"
instead, hence the value of 1 being used as an address. A rebuild
against the new pthread.h will fix this but not for old libraries.
I will swap the order of "clock_id" and "waiting" now.
If python is then compiled against this new pthread.h and run using an
old unixlib, then it will allocate an object larger than necessary
(which is OK) and "waiting" will be in the right place.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Thursday, 23 July 2020
Re: [gccsdk] New SharedLibs incompatibility
I'd better get compiling.
However, if I build it again the new libs I assume it won't work with
the older ones?
Cheers
Chris
On 23/07/2020 15:56, Lee Noar wrote:
> On 23/07/2020 12:38, David Pitt wrote:
>
>> Is r7347 the full fix?
>
> Yes, that fixes the Invalid argument error.
>
>> Previously running Python38a6 this was the error ;-
>>
>> pthread_cond_init: Invalid argument
>> Fatal Python error: _PyRuntimeState_Init_impl: Can't initialize
>> threads for interpreter
>> Python runtime state: unknown
>>
>> With r7347 and full rebuild of both build-world and ronative I get
>> this :-
>>
>> Fatal signal received: Segmentation fault
>>
>> Stack backtrace:
>>
>> Running thread 0x293344 (Main Thread)
>> ( 807f34) pc: 474e9e34 lr: 474ea250 sp: 807f38
>> __write_backtrace()
>> ( 807fa0) pc: 474e9f84 lr: 474ebd54 sp: 807fa4
>> __unixlib_raise_signal()
>> ( 807fb0) pc: 474ebc3c lr: 474ca418 sp: 806c9c __h_cback()
>>
>> Register dump at 00807fb4:
>>
>> a1: 204da3b0 a2: 1 a3: 1 a4: 1
>> v1: 2bb7e4 v2: 2bb7e0 v3: 2bc4a0 v4: 284808
>> v5: 2888d0 v6: 806e38 sl: 806208 fp: 806cac
>> ip: 204da354 sp: 806c9c lr: 474ca418 pc: 474ca428
>> cpsr: 20000010
>>
>> 474ca414 : ��� : ebfdee8a : BL &47445E44
>> 474ca418 : .0�� : e5943004 : LDR R3,[R4,#4]
>> 474ca41c : ..S� : e3530000 : CMP R3,#0
>> 474ca420 : H!�. : 15932148 : LDRNE R2,[R3,#328]
>> 474ca424 : ..�. : 13a01007 : MOVNE R1,#7
>> 474ca428 : ... : 15831118 : STRNE R1,[R3,#280]
>> 474ca42c : . . : 15842004 : STRNE R2,[R4,#4]
>> 474ca430 : ���� : ebfdf0ff : BL &47446834
>> 474ca434 : ..�� : e3a00000 : MOV R0,#0
>>
>> ( 806cac) pc: 474ca404 lr: 12f604 sp: 806cb0
>> pthread_cond_signal()
>> ( 806cc8) pc: 12f5d4 lr: 11c080 sp: 806ccc
>> PyThread_release_lock()
>> ( 806ce8) pc: 11bfac lr: 11a440 sp: 806cec
>> PyInterpreterState_New()
>> ( 806e24) pc: 11a2a8 lr: 11aa6c sp: 806e28
>> pyinit_core.constprop.10()
>> ( 806e68) pc: 11aa28 lr: 2b368 sp: 806e6c
>> Py_InitializeFromConfig()
>> ( 806f90) pc: 2b2bc lr: 2c368 sp: 806f94 pymain_init()
>> ( 806fdc) pc: 2c334 lr: 21348 sp: 806fe0 Py_BytesMain()
>> ( 806fec) pc: 2133c lr: 47500cc0 sp: 806ff0 main()
>
> I've just realised that this could be due to __pthread_cond
> increasing in size to support a relative clock_id. Any old code
> will assume the old size, so if python is built against an old
> pthread.h header, it will be using the old size.
>
> Lee.
>
> _______________________________________________
> GCCSDK mailing list gcc@gccsdk.riscos.info
> Bugzilla: http://www.riscos.info/bugzilla/index.cgi
> List Info: http://www.riscos.info/mailman/listinfo/gcc
> Main Page: http://www.riscos.info/index.php/GCCSDK
--
This email has been checked for viruses by AVG.
https://www.avg.com
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] New SharedLibs incompatibility
On 23/07/2020 12:38, David Pitt wrote:
> Is r7347 the full fix?
Yes, that fixes the Invalid argument error.
> Previously running Python38a6 this was the error ;-
>
> pthread_cond_init: Invalid argument
> Fatal Python error: _PyRuntimeState_Init_impl: Can't initialize
> threads for interpreter
> Python runtime state: unknown
>
> With r7347 and full rebuild of both build-world and ronative I get
> this :-
>
> Fatal signal received: Segmentation fault
>
> Stack backtrace:
>
> Running thread 0x293344 (Main Thread)
> ( 807f34) pc: 474e9e34 lr: 474ea250 sp: 807f38
> __write_backtrace()
> ( 807fa0) pc: 474e9f84 lr: 474ebd54 sp: 807fa4
> __unixlib_raise_signal()
> ( 807fb0) pc: 474ebc3c lr: 474ca418 sp: 806c9c __h_cback()
>
> Register dump at 00807fb4:
>
> a1: 204da3b0 a2: 1 a3: 1 a4: 1
> v1: 2bb7e4 v2: 2bb7e0 v3: 2bc4a0 v4: 284808
> v5: 2888d0 v6: 806e38 sl: 806208 fp: 806cac
> ip: 204da354 sp: 806c9c lr: 474ca418 pc: 474ca428
> cpsr: 20000010
>
> 474ca414 : ��� : ebfdee8a : BL &47445E44
> 474ca418 : .0�� : e5943004 : LDR R3,[R4,#4]
> 474ca41c : ..S� : e3530000 : CMP R3,#0
> 474ca420 : H!�. : 15932148 : LDRNE R2,[R3,#328]
> 474ca424 : ..�. : 13a01007 : MOVNE R1,#7
> 474ca428 : ... : 15831118 : STRNE R1,[R3,#280]
> 474ca42c : . . : 15842004 : STRNE R2,[R4,#4]
> 474ca430 : ���� : ebfdf0ff : BL &47446834
> 474ca434 : ..�� : e3a00000 : MOV R0,#0
>
> ( 806cac) pc: 474ca404 lr: 12f604 sp: 806cb0
> pthread_cond_signal()
> ( 806cc8) pc: 12f5d4 lr: 11c080 sp: 806ccc
> PyThread_release_lock()
> ( 806ce8) pc: 11bfac lr: 11a440 sp: 806cec
> PyInterpreterState_New()
> ( 806e24) pc: 11a2a8 lr: 11aa6c sp: 806e28
> pyinit_core.constprop.10()
> ( 806e68) pc: 11aa28 lr: 2b368 sp: 806e6c
> Py_InitializeFromConfig()
> ( 806f90) pc: 2b2bc lr: 2c368 sp: 806f94 pymain_init()
> ( 806fdc) pc: 2c334 lr: 21348 sp: 806fe0 Py_BytesMain()
> ( 806fec) pc: 2133c lr: 47500cc0 sp: 806ff0 main()
I've just realised that this could be due to __pthread_cond
increasing in size to support a relative clock_id. Any old code
will assume the old size, so if python is built against an old
pthread.h header, it will be using the old size.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] New SharedLibs incompatibility
In message <589496c3efronanon@zoho.com>
Ron <ronanon@zoho.com> wrote:
> In article <d6bd8b9458.pittdj+@iyonix.home>,
> David Pitt <pittdj@pittdj.co.uk> wrote:
>> With r7347 and full rebuild of both build-world and ronative I get
>> this :-
> I made the mistake of not doing make ronative-clean (or clean-ronative?)
> and got another copy of release 3, just saying in case someone assumes
> that it's already done.
Initially I did 'make clean' in gcc4 to get build-world to run again.
Then to make sure the build really was clean gccdsk was deleted and a
completely new build done. The Titanium was rebooted before every
test.
--
David Pitt
Titanium
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Ron <ronanon@zoho.com> wrote:
> In article <d6bd8b9458.pittdj+@iyonix.home>,
> David Pitt <pittdj@pittdj.co.uk> wrote:
>> With r7347 and full rebuild of both build-world and ronative I get
>> this :-
> I made the mistake of not doing make ronative-clean (or clean-ronative?)
> and got another copy of release 3, just saying in case someone assumes
> that it's already done.
Initially I did 'make clean' in gcc4 to get build-world to run again.
Then to make sure the build really was clean gccdsk was deleted and a
completely new build done. The Titanium was rebooted before every
test.
--
David Pitt
Titanium
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] New SharedLibs incompatibility
In message <a39ee097-8988-9994-1353-2323af3355bf@sky.com>
Lee Noar <lee.noar@sky.com> wrote:
> On 22/07/2020 08:04, alan buckley wrote:
>> The new version of the shared C libraries I�ve just released alongside
>> the new GCC release for RISC OS seem to be incompatible with programs
>> compiled against the previous version of GCC.
>>
>> I tried the Python3 download yesterday against the new shared libs and
>> it crashed complaining about pthread_cond.
[snip]
>> How should this be fixed?
> Fortunately, it's a fairly easy fix, and I'll have it fixed shortly.
> It effects both the shared and static Unixlib libraries, but nothing
> else.
Is r7347 the full fix?
Previously running Python38a6 this was the error ;-
pthread_cond_init: Invalid argument
Fatal Python error: _PyRuntimeState_Init_impl: Can't initialize
threads for interpreter
Python runtime state: unknown
With r7347 and full rebuild of both build-world and ronative I get
this :-
Fatal signal received: Segmentation fault
Stack backtrace:
Running thread 0x293344 (Main Thread)
( 807f34) pc: 474e9e34 lr: 474ea250 sp: 807f38
__write_backtrace()
( 807fa0) pc: 474e9f84 lr: 474ebd54 sp: 807fa4
__unixlib_raise_signal()
( 807fb0) pc: 474ebc3c lr: 474ca418 sp: 806c9c __h_cback()
Register dump at 00807fb4:
a1: 204da3b0 a2: 1 a3: 1 a4: 1
v1: 2bb7e4 v2: 2bb7e0 v3: 2bc4a0 v4: 284808
v5: 2888d0 v6: 806e38 sl: 806208 fp: 806cac
ip: 204da354 sp: 806c9c lr: 474ca418 pc: 474ca428
cpsr: 20000010
474ca414 : ��� : ebfdee8a : BL &47445E44
474ca418 : .0�� : e5943004 : LDR R3,[R4,#4]
474ca41c : ..S� : e3530000 : CMP R3,#0
474ca420 : H!�. : 15932148 : LDRNE R2,[R3,#328]
474ca424 : ..�. : 13a01007 : MOVNE R1,#7
474ca428 : ... : 15831118 : STRNE R1,[R3,#280]
474ca42c : . . : 15842004 : STRNE R2,[R4,#4]
474ca430 : ���� : ebfdf0ff : BL &47446834
474ca434 : ..�� : e3a00000 : MOV R0,#0
( 806cac) pc: 474ca404 lr: 12f604 sp: 806cb0
pthread_cond_signal()
( 806cc8) pc: 12f5d4 lr: 11c080 sp: 806ccc
PyThread_release_lock()
( 806ce8) pc: 11bfac lr: 11a440 sp: 806cec
PyInterpreterState_New()
( 806e24) pc: 11a2a8 lr: 11aa6c sp: 806e28
pyinit_core.constprop.10()
( 806e68) pc: 11aa28 lr: 2b368 sp: 806e6c
Py_InitializeFromConfig()
( 806f90) pc: 2b2bc lr: 2c368 sp: 806f94 pymain_init()
( 806fdc) pc: 2c334 lr: 21348 sp: 806fe0 Py_BytesMain()
( 806fec) pc: 2133c lr: 47500cc0 sp: 806ff0 main()
--
David Pitt
Titanium
Lee Noar <lee.noar@sky.com> wrote:
> On 22/07/2020 08:04, alan buckley wrote:
>> The new version of the shared C libraries I�ve just released alongside
>> the new GCC release for RISC OS seem to be incompatible with programs
>> compiled against the previous version of GCC.
>>
>> I tried the Python3 download yesterday against the new shared libs and
>> it crashed complaining about pthread_cond.
[snip]
>> How should this be fixed?
> Fortunately, it's a fairly easy fix, and I'll have it fixed shortly.
> It effects both the shared and static Unixlib libraries, but nothing
> else.
Is r7347 the full fix?
Previously running Python38a6 this was the error ;-
pthread_cond_init: Invalid argument
Fatal Python error: _PyRuntimeState_Init_impl: Can't initialize
threads for interpreter
Python runtime state: unknown
With r7347 and full rebuild of both build-world and ronative I get
this :-
Fatal signal received: Segmentation fault
Stack backtrace:
Running thread 0x293344 (Main Thread)
( 807f34) pc: 474e9e34 lr: 474ea250 sp: 807f38
__write_backtrace()
( 807fa0) pc: 474e9f84 lr: 474ebd54 sp: 807fa4
__unixlib_raise_signal()
( 807fb0) pc: 474ebc3c lr: 474ca418 sp: 806c9c __h_cback()
Register dump at 00807fb4:
a1: 204da3b0 a2: 1 a3: 1 a4: 1
v1: 2bb7e4 v2: 2bb7e0 v3: 2bc4a0 v4: 284808
v5: 2888d0 v6: 806e38 sl: 806208 fp: 806cac
ip: 204da354 sp: 806c9c lr: 474ca418 pc: 474ca428
cpsr: 20000010
474ca414 : ��� : ebfdee8a : BL &47445E44
474ca418 : .0�� : e5943004 : LDR R3,[R4,#4]
474ca41c : ..S� : e3530000 : CMP R3,#0
474ca420 : H!�. : 15932148 : LDRNE R2,[R3,#328]
474ca424 : ..�. : 13a01007 : MOVNE R1,#7
474ca428 : ... : 15831118 : STRNE R1,[R3,#280]
474ca42c : . . : 15842004 : STRNE R2,[R4,#4]
474ca430 : ���� : ebfdf0ff : BL &47446834
474ca434 : ..�� : e3a00000 : MOV R0,#0
( 806cac) pc: 474ca404 lr: 12f604 sp: 806cb0
pthread_cond_signal()
( 806cc8) pc: 12f5d4 lr: 11c080 sp: 806ccc
PyThread_release_lock()
( 806ce8) pc: 11bfac lr: 11a440 sp: 806cec
PyInterpreterState_New()
( 806e24) pc: 11a2a8 lr: 11aa6c sp: 806e28
pyinit_core.constprop.10()
( 806e68) pc: 11aa28 lr: 2b368 sp: 806e6c
Py_InitializeFromConfig()
( 806f90) pc: 2b2bc lr: 2c368 sp: 806f94 pymain_init()
( 806fdc) pc: 2c334 lr: 21348 sp: 806fe0 Py_BytesMain()
( 806fec) pc: 2133c lr: 47500cc0 sp: 806ff0 main()
--
David Pitt
Titanium
Wednesday, 22 July 2020
Re: [gccsdk] New SharedLibs incompatibility
On 22/07/2020 16:57, alan buckley wrote:
> Lee Noar <mailto:lee.noar@sky.com> wrote on 22 July 2020 11:30:
> > Fortunately, it's a fairly easy fix, and I'll have it fixed shortly.
> > It effects both the shared and static Unixlib libraries, but nothing
> > else.
>
> Thanks for that Lee. How to I go about getting this into the wild?
>
> svn update and then ./build-world?
./build-world only does the cross compiler, you'll have to do:
make ronative
as well to rebuild the libraries in the native compiler. I think that's
where the packaged libraries come from.
> I assume I�ll have to create GCC 4.7.4 release 5 packages as I assume
> I can�t get away with just updating the shared c library package.
That's right, the static libraries within !GCC will need updating also.
Thanks,
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
> Lee Noar <mailto:lee.noar@sky.com> wrote on 22 July 2020 11:30:
> > Fortunately, it's a fairly easy fix, and I'll have it fixed shortly.
> > It effects both the shared and static Unixlib libraries, but nothing
> > else.
>
> Thanks for that Lee. How to I go about getting this into the wild?
>
> svn update and then ./build-world?
./build-world only does the cross compiler, you'll have to do:
make ronative
as well to rebuild the libraries in the native compiler. I think that's
where the packaged libraries come from.
> I assume I�ll have to create GCC 4.7.4 release 5 packages as I assume
> I can�t get away with just updating the shared c library package.
That's right, the static libraries within !GCC will need updating also.
Thanks,
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] New SharedLibs incompatibility
Lee Noar wrote on 22 July 2020 11:30:
> > On 22/07/2020 08:04, alan buckley wrote:
> > The new version of the shared C libraries I�ve just released alongside
> > the new GCC release for RISC OS seem to be incompatible with programs
> > compiled against the previous version of GCC.
> >
> > I tried the Python3 download yesterday against the new shared libs and
> > it crashed complaining about pthread_cond.
> >
> > Any ideas why this may be? Has the abi changed? or is it something more
> > subtle?
> The good news is that this is nothing to do with dynamic linking. The
> (mildly) bad news is that I made a mistake in r7252. I must have misread
> the spec for pthread_cond_init and changed it to reject a NULL
> attribute. In fact a NULL attribute is valid and means use the default
> values.
> > How should this be fixed?
> Fortunately, it's a fairly easy fix, and I'll have it fixed shortly.
> It effects both the shared and static Unixlib libraries, but nothing
> else.
Thanks for that Lee. How to I go about getting this into the wild?
svn update and then ./build-world?
I assume I'll have to create GCC 4.7.4 release 5 packages as I assume
I can't get away with just updating the shared c library package.
Regards,
Alan
Subscribe to:
Posts (Atom)