Skip to contentSkip to conversation

package/python-cramjam: new package

PATCH RESEND Flaviu Nistor 2 participants 3 messages Oct 13 – Oct 15 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Flaviu Nistor

author
#1 lore raw
Quoted 51 lines · Peter Korsgaard

Hi,

Quoted 7 lines

Review line 3

Quoted 5 lines

+++ b/package/python-cramjam/Config.in

(quoted diff) +3 -0
@@ -0,0 +1,9 @@
+config BR2_PACKAGE_PYTHON_CRAMJAM
+	bool "python-cramjam"
+	depends on !BR2_ARM_CPU_ARMV5

Why? Perhaps you mean BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS?

I saw that you were explicitly not testing with our default armv5 kernel, so I gave it a try and the code indeed seems to be buggy:

Reading symbols from python3...
(gdb) run -c 'import cramjam'
Starting program: /usr/bin/python3 -c 'import cramjam' [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1".
random: python3: uninitialized urandom read (24 bytes read)

Program received signal SIGSEGV, Segmentation fault.
0xb68e42dc in strcmp () from /lib/libc.so.6
(gdb) bt
#0 0xb68e42dc in strcmp () from /lib/libc.so.6
#1 0xb6ca6584 in _PyImport_ResolveNameWithPackageContext (name=0x0)
at Python/import.c:846
#2 0xb6b7385c in _PyModule_CreateInitialized (module=0xb6701808,
module_api_version=<optimized out>) at Objects/moduleobject.c:233
#3 0xb6348018 in ?? ()
from /usr/lib/python3.14/site-packages/cramjam/cramjam.cpython-314-arm-linux-gnueabi.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) random: crng init done
info registers

r0             0x0                 0
r1             0xb670b3d4          3060839380
r2             0x0                 0
r3             0x0                 0
r4             0x0                 0
r5             0xb670b3cc          3060839372
r6             0xb6848508          3062138120
r7             0x8                 8
r8             0xb6701808          3060799496
r9             0xbebaa064          3199901796
r10            0xb6f0d538          3069236536
r11            0xb6767f48          3061219144
r12            0xb6ec4a40          3068938816
sp             0xbeba9e50          0xbeba9e50
lr             0xb6ca6584          3066717572
pc             0xb68e42dc          0xb68e42dc <strcmp+84>
cpsr           0x60000010          1610612752
Quoted 6 lines

So presumably something is not initialized to cause this null pointer exception. The fact that PyImport_ResolveNameWithPackageContext gets called with a null pointer is already odd.

Care to report it upstream? I see that there is in the mean time a 2.13 release.

I saw a related issue reported with a similar topic that it can't be tested on 32-bit architectures. This is way I specified depends on !BR2_ARM_CPU_ARMV5, since at that time I found no other solution. I have tested today and version 2.14.0 (released today) does not have this issue any more, so it runs on armv5. James Hilliard just send a bump for 2.14.0, so for v5 I will not include this. Here is the link to the bump:
https://lore.kernel.org/all/[email protected]/

Thanks for support,
Flaviu

Quoted 3 lines
Signature · 2 lines
-- 
Bye, Peter Korsgaard

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

#2 lore raw
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Flaviu" == Flaviu Nistor <[email protected]> writes:

Hi,

Quoted 9 lines
Quoted 6 lines

So presumably something is not initialized to cause this null pointer exception. The fact that PyImport_ResolveNameWithPackageContext gets called with a null pointer is already odd.

Care to report it upstream? I see that there is in the mean time a 2.13 release.

I saw a related issue reported with a similar topic that it can't be tested on 32-bit architectures. This is way I specified depends on !BR2_ARM_CPU_ARMV5,

OK, but then it should presumably have been blocked on all 32bit architectures and not just ARMv5. This is really the kind of nonobvious stuff that should go into the commit message.

Quoted 5 lines

since at that time I found no other solution. I have tested today and version 2.14.0 (released today) does not have this issue any more, so it runs on armv5. James Hilliard just send a bump for 2.14.0, so for v5 I will not include this. Here is the link to the bump:
https://lore.kernel.org/all/[email protected]/

OK, good.

Signature · 5 lines
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
author
#3 lore raw
Quoted 9 lines · Peter Korsgaard

Hi,

Quoted 6 lines
Quoted 6 lines

So presumably something is not initialized to cause this null pointer exception. The fact that PyImport_ResolveNameWithPackageContext gets called with a null pointer is already odd.

Care to report it upstream? I see that there is in the mean time a 2.13 release.

Quoted 7 lines
Quoted 2 lines

I saw a related issue reported with a similar topic that it can't be tested on 32-bit architectures. This is way I specified depends on !BR2_ARM_CPU_ARMV5,

OK, but then it should presumably have been blocked on all 32bit architectures and not just ARMv5. This is really the kind of nonobvious stuff that should go into the commit message.

Yes, you are write. I have checked after your initial reply and also armv7 was failing. Once I realized that 32-bit will fail I switch directly to aarch64 and forget to include also armv7 together with armv5.
In similar situations I will take care in the future to explain such details in the commit.

Quoted 10 lines
Quoted 5 lines

since at that time I found no other solution. I have tested today and version 2.14.0 (released today) does not have this issue any more, so it runs on armv5. James Hilliard just send a bump for 2.14.0, so for v5 I will not include this. Here is the link to the bump:
https://lore.kernel.org/all/[email protected]/

OK, good.

Signature · 1 line
Bye, Peter Korsgaard

Thanks again,
Flaviu Nistor
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot