Re: Debugging Epiphany/Midori (webkit-gtk based) on earmv6hf (RPI 2)

[Stephan]

After looking at the code, I´m pretty certain it´s the JavaScriptCore
JIT compiler* who generates some assembly on a heap segment which then
calls library functions with a misaligned stack pointer. The version
of webkit-gtk which I built from a recent pkgsrc release is 2.4.8. The
best thing to do first is trying the current version (2.10) of
webkit-gtk I guess.


* 
https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/assembler/ARMAssembler.h


2015-10-14 7:56 GMT+02:00 Stephan :
> 2015-10-13 21:34 GMT+02:00 Nick Hudson :
>> On 10/13/15 17:58, Stephan wrote:
>>
>>>
>>> Breakpoint 1, 0x46213ff4 in g_dpgettext2 () from
>>> /usr/pkg/lib/libglib-2.0.so.0
>>> (gdb) i r $r12
>>> r120x7fffb8c8   2147465416
>>>
>>> Breakpoint 1, 0x46213ff4 in g_dpgettext2 () from
>>> /usr/pkg/lib/libglib-2.0.so.0
>>> (gdb) i r $r12
>>> r120x7fffb870   2147465328
>>>
>>> Contrary, sp is broken in the non-working case:
>>>
>>> (gdb) i r $r12
>>> r120x7fffa414   2147460116
>>>
>>> Unfortunately, the call trace is incomplete in that case:
>>
>> r13 is sp.
>
> Sure. When I use gdb, I set a breakpoint on . In practise,
> the breakpoint hits after the stack frame was set up by that function,
> e.g. when sp was already lowered to allocate space for local variables
> (or the stack pointer was potentially aligned like gcc on x86 does).
> On gcc/ARM, ip (r12) gets a copy of sp on the first instruction of the
> function prologue. That´s why I monitored r12 (another solution could
> be to break on *function+0, but I haven´t tested that).
>
>>
>> debug symbols (compile flag -g) will help a lot here.
>>
>
> Uff... ATM it looks like Webkit is at fault. It took 2 days to compile
> on the RPI2 so it could take a long time to get the symbols ready.
> Also the last thing I´ve seen yesterday was that the frame where gdb
> stopped being able to follow the stack was special. Basically
> speaking, I think the condition that makes this crash happen is when a
> new tab/page is supposed to open from a JavaScript event - so it´s
> likely that the JS interpreter is on the call trace. The code to the
> said frame where gdb stops was executable memory (rwx) residing in an
> [anon] region. I´m not sure whether symbols can help in this case nor
> what else can... ;)
>
>>
>> Nick

Re: Ways to report trace when boot panics [Was NetBSD 7.0 i386 panic during boot]

[Brett Lymn]

On Mon, Oct 12, 2015 at 09:32:13PM +0700, Robert Elz wrote:
> 
> Joerg Sonnenberger   said:
>  | You don't need "just" a cable, but one with quite a bit logic in between.
>  | USB is not designed for host-to-host communication,
> 
> Thanks - that's the kind of info I was lacking, given I know nothing about
> USB...   I had naively assumed that something which calls itself a
> universal serial bus would actually have some of the characteristics that
> would justify such a name.
> 

But it does - it is exactly like an old school computer bus, it has one
controller (usually your computer) with devices connected to it.  It is
a pretty primitive bus, the controller has to poll all the devices on
the bus to see if they want to do something, there are no real
interrupts at all.  New devices on the bus are done using a bit of a
signalling dance involving deliberately breaking the protocol - very
much similar to a rs-232 break signal.  

> I was kind of anticipating there might be issues with USB power, but I
> had a vague understanding that it might be possible to control that.
> 

Power is fine, the standard allows for multiple devices to power the bus
the complexity is in the multiphase protocol required to put data across
the bus and that it is really only designed to have a single controller
on the bus and most computers expect to be that controller so they
aren't equipped to become a client on another controllers bus.  Also the
usb A to usb A cable is an illegal configuration according to the USB
spec - you can get them but they are not a common thing because it is a
breach of the spec.

> Also might be useful I guess, perhaps allowing one of those small systems
> to act as a console for any other system being debugged, but again, not
> really very general.   Lack of support (currently) isn't necessarily a 
> problem,
> none of this currently has any support - any of it would require lots of
> code to be written.
> 

AFAIU you need hardware that supports OTG, I don't think it is a common
thing in most computer hardware.  So you would have to have a special
thing to make this work.

> Mayuresh   said:
>  | Even nicer if such device could be a smartphone,
> 
> That's looking like perhaps a better choice - phones are already "devices"
> rather than hosts aren't they?  And they are almost as common as USB, so
> requiring that would not be overly limiting.   Of course, I have no idea
> whether it is possible on those systems to get low level enough access to
> implement something like this.
> 

Yes, they are devices.  You could possibly get an implementation of MTP
(media transfer protocol) up and going to write out a file, most phones
support MTP I believe but it does mean doing the usb protocol and then
layering the mtp over the top.  First step would be to get a polled mode
USB transfer going, technically not impossible but it does mean a lot of
work for someone

-- 
Brett Lymn
Let go, or be dragged - Zen proverb.

daily CVS update output

[NetBSD source update]

Updating src tree:
P src/etc/rc.d/mdnsd
P src/external/apache2/mDNSResponder/dist/mDNSCore/DNSCommon.c
P src/external/apache2/mDNSResponder/dist/mDNSCore/mDNS.c
P src/external/apache2/mDNSResponder/dist/mDNSPosix/PosixDaemon.c
P src/external/apache2/mDNSResponder/dist/mDNSPosix/mDNSPosix.c
P src/external/apache2/mDNSResponder/dist/mDNSShared/PlatformCommon.c
P src/gnu/usr.bin/groff/tmac/mdoc.local
P src/libexec/lfs_cleanerd/lfs_cleanerd.c
P src/sbin/dump_lfs/lfs_inode.c
P src/sbin/fsck_lfs/lfs.c
P src/sbin/newfs_lfs/extern.h
P src/sbin/newfs_lfs/make_lfs.c
P src/sbin/newfs_lfs/newfs.c
P src/sbin/newfs_lfs/newfs_lfs.8
P src/sbin/scan_ffs/scan_ffs.c
P src/sys/arch/arm/arm/cpufunc.c
P src/sys/arch/arm/cortex/a9_mpsubr.S
P src/sys/arch/arm/include/armreg.h
P src/sys/arch/arm/nvidia/tegra_ahcisata.c
P src/sys/arch/arm/nvidia/tegra_ahcisatareg.h
P src/sys/arch/arm/nvidia/tegra_pcie.c
P src/sys/arch/arm/nvidia/tegra_pciereg.h
P src/sys/arch/evbarm/conf/std.tegra
P src/sys/arch/sandpoint/stand/altboot/brdsetup.c
P src/sys/dev/gpio/files.gpio
P src/sys/dev/i2c/axp20x.c
U src/sys/dev/i2c/axp20xvar.h
P src/sys/dev/sysmon/sysmon_envsys_events.c
P src/sys/sys/syslog.h
P src/sys/ufs/lfs/lfs.h
P src/sys/ufs/lfs/lfs_accessors.h
P src/sys/ufs/lfs/lfs_syscalls.c
P src/sys/ufs/lfs/lfs_vfsops.c
P src/sys/ufs/lfs/ulfsmount.h
P src/tools/gcc/gcc-version.mk
P src/usr.sbin/dumplfs/dumplfs.c

Updating xsrc tree:


Killing core files:

Running the SUP scanner:
SUP Scan for current starting at Fri Oct 16 04:04:14 2015
SUP Scan for current completed at Fri Oct 16 04:05:31 2015
SUP Scan for mirror starting at Fri Oct 16 04:05:31 2015
SUP Scan for mirror completed at Fri Oct 16 04:10:22 2015




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  54925005 Oct 16 04:21 ls-lRA.gz

Re: Killing a zombie process?

[Rhialto]

On Thu 15 Oct 2015 at 06:57:42 +0700, Robert Elz wrote:
> I do wonder about ...
> 
>   | procfs on /usr/pkg/emul/linux32/proc type procfs (read-only, local)
>   | procfs on /usr/pkg/emul/linux32/proc type procfs (local)

Ah good catch. That seems to be a botched attempt to mount the linux
procfs /inside/ the chroot. But I made a typo somewhere.
That used to be needed in the past for building some package I think,
but since I don't have it on my main machine that is probably not true
any more.

> Especially since some of the tstile processes you showed are doing
> lookups under namei_tryemulroot()

However the getcwds should not come near that proc directory, since it
is outside the chroot.

> Do you really need that mounted twice like that, and if not, can you try
> with one of them missing and see if the problem remains ?

Good idea, I'll try that later!

> kre
-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'


pgps_cMO0dZAW.pgp
Description: PGP signature