#parrot Parrot 0.6.1 "Bird of Paradise" Released | parrotcode.org
Set by moderator on 22 April 2008.
00:11 shamu joined 00:20 Limbic_Region joined 01:28 Theory joined
tetragon Got the backtrace working with dladdr on OS X 02:08
I'm having some difficulty in getting Linux to play nice with my (non-parrot) test code for it. 02:09
02:10 Andy joined
nopaste "tetragon" at 69.196.138.185 pasted "Nifty backtrace patch that uses dladdr. Not tested on non-OS X 10.5" (46 lines) at nopaste.snit.ch/12834 02:17
Debolaz watches perl6.pmc and his nifty little test script make parrot crash and burn 02:24
PerlJam What's perl6.pmc ? 02:25
Debolaz s/pmc/pbc/ 02:26
When I encounter such things, where do I send the information and what exactly do I include in the report aside from the test script?
Tene Debolaz: it's polite to also send the output, a backtrace if you can get it, all the information you can get. 02:50
purl: parrotbug 02:51
purl i think parrotbug is mailto:parrotbug@parrotcode.org or svn.perl.org/parrot/trunk/docs/submissions.pod
dalek r27199 | infinoid++ | trunk:
: [src] Add autogenerated file glut_callbacks.c to svn:ignore.
diff: www.parrotvm.org/svn/parrot/revision?rev=27199
Infinoid tetragon: works fine on linux/amd64/ no warnings, output is about the same as the parse-backtrace_symbols() version 02:56
tetragon Oh good
Some of my Linux i386 tests were crashing without additional checks
I'll stick them in and retest/repost
Infinoid only difference in output is the unknown symbols have transformed from "(unknown)" to "(null)" 02:57
we're going to need to probe for dladdr() tho... I bet win32 doesn't have it.
dalek r27200 | chromatic++ | trunk:
tetragon I think that may be a difference between glibcs/platforms
dalek : [GC] Fixed PMC_EXT allocation/deallocation.
: PMC_EXT structures are *not* isomorphic with the PObj structure. Treating it 02:58
: as such was an unnecessary hack that is now gone. There is one smaller hack in
: the revised version, but it's part of the free list pointer hack that's already
: in the code, and it's much better than the troublesome casting and
: bit-twiddling necessary to treat PMC_EXT headers and PObj headers somewhat
: interchangeably.
diff: www.parrotvm.org/svn/parrot/revision?rev=27200
tetragon I've encountered differences in behaviour in standard functions between i386 and amd64 before
Infinoid I can test on linux/i686 if needed
actually, the readability of stack backtraces will vary depending on compiler version and options, too 02:59
tetragon I think the amd64 one adds in (null) as my i386 tests just segfault if I don't explicitly test first
Infinoid no, that's a feature of later glibc versions, it does that when you try to printf("%s") a NULL pointer
I've seen it on x86 too
tetragon Hrm
Well, my i386 test box doesn't have that behaviour 03:00
So I'm adding in an explicit test
Infinoid please do :)
its nice to have, but you can't rely on it 03:01
nopaste "tetragon" at 69.196.138.185 pasted "Now with an added NULL pointer check" (46 lines) at nopaste.snit.ch/12835 03:02
Infinoid now they're (unknown)s again 03:04
diff looks great, but we definitely will need to probe for dladdr(), dlfcn.h and the Dl_info typedef 03:05
tetragon All OS X versions that have backtrace have everything I added (easy to say when there's only one version with backtrace(3)) 03:06
Infinoid yeah, OS X does a fairly good job of having the normal POSIXish features 03:07
to be honest, it's win32 I'm worried about.
tetragon I don't have access to that platform
Infinoid I do. I'm going to test on mingw as soon as this silly box reboots again 03:08
tetragon One difference between OS X and Linux/glibc for this is that glibc requires that _GNU_SOURCE be defined before dlfcn.h is imported. OS X lacks that requirement
Infinoid why, is dladdr considered a GNU extension, or something? 03:09
tetragon The typedef and dladdr are only defined in that case
According to the manpage on Linux, it is
Infinoid holds his skull painfully
tetragon Since it worked for you, _GNU_SOURCE is probably defined somewhere 03:10
Infinoid its in CFLAGS in the toplevel Makefile
tetragon And it was that requirement that was causing me so much grief when it came to a simple test on Linux
Infinoid added by config/init/hints/linux.pm 03:11
it didn't get added on your linux box?
or were you compiling something by hand? 03:12
tetragon Simple test by hand
Infinoid ok
tetragon The thing that gets to me is how much shorter the dladdr version of the function is when compared against the backtrace_symbols parsing variant 03:16
Infinoid all right! I finally figured out how to download a URL from a command prompt
tetragon wget? 03:17
purl well, wget is http/ftp file retrieval client or a good way to download stuff or `echo "robots=off" >> ~/.wgetrc` or web 3.0
Infinoid wget didn't exist, GET didn't exist, but lwp-download.bat does
so now I get to remember where the weird port of the patch command is...
tetragon tries to remember enough edlin to see if an ed diff is close enough to work 03:18
Infinoid if I did this more often, I'd get better at it.
building now 03:19
no, failing to configure. *sigh* 03:22
ok, I won't be able to test this until monday 03:26
(gcc can't create executables after windows explorer has crashed, and I can't do a hard reboot remotely) 03:27
tetragon I've stuck the patch into the ticket
(#53402) 03:28
Infinoid cool. 03:31
in theory, this shouldn't break anything. win32 should fail to detect backtrace(), which means all this code should be disabled anyway
tetragon And all systems I know of with backtrace() have dladdr in dlfcn.h 03:33
Infinoid a lucky coincidence :)
tetragon And dladdr came to OS X and glibc from Solaris/SunOS 03:34
tetragon wonders if they have backtrace(3) 03:35
Infinoid cvs.opensolaris.org/source/xref/onn...o.h?r=3988 03:36
tetragon Looks like it may have been recently added
shorten Infinoid's url is at xrl.us/bju78 03:37
tetragon ko.opensolaris.org/os/community/arc...E8B8B33E8F
shorten tetragon's url is at xrl.us/bju8a
03:38 Andy joined
Infinoid opensolaris is moving at surprising speed, considering 03:38
dalek r27201 | chromatic++ | trunk: 03:52
: [GC] Fixed some casts from r27200.
diff: www.parrotvm.org/svn/parrot/revision?rev=27201
04:17 Zaba_ joined 04:28 teknomunk joined 04:30 Psyche^ joined 04:40 tetragon joined
tetragon Hey, test 6 of t/dynoplibs/myops.t stopped passing 04:43
Infinoid due to the recent GC changes? or... 04:44
tetragon The last two output lines are in the wrong order
Infinoid any chance of finding out why? :) 04:45
(I'm unable to reproduce on linux) 04:46
tetragon Hrm... That ordering issue hasn't repeated in the last few times I've run the code
Infinoid ah, intermittant 04:47
Infinoid runs 100 of them in a shell loop 04:48
tetragon I've only seen that behaviour once
Infinoid this "three alarms" thingy is sounding vaguely familiar to me, I think I've seen it a few times too 04:49
04:50 slightlyoff joined
tetragon Try running the process niced down as far as you can go while building perl6 04:52
(Or something else to load up your CPU)
I can reproduce similar issues in that case
(More first couple lines than last pair)
I've just gotten a string of 2-1-3 to come out instead of 1-2-3 04:53
And I just got a 1-3-2
It seems like CPU load can cause the test to fall over
Infinoid tetragon: I was seeing intermittant "three alarms" failures on MSVC/win32 on May 14, 2007
tetragon And I'm triggering fairly consistent failures on OS X 04:54
Infinoid if your failures have the same cause, its an *old* bug
tetragon I don't know the win32 cause, but my one seems related to CPU load possibly causing the "sleep 1" to last longer than it should
Infinoid I think I had patched this at some point to try to spread out the events a little more, but it doesn't look like that ever got committed 04:56
50 passes in a row on amd64, 25 passes in a row on i686 so far 04:57
Infinoid spawns some forkbombs to see if he can trigger it
that did it. got a 2-1-3 on linux-i686 with a loadavg of 15. 05:01
tetragon I think the most likely explanation for my first failure would be system load 05:03
Infinoid absolutely. it's very consistent when loadavg=15 05:04
tetragon My box would have still been dealing with the crash reporter due to the test 3 crash, and the crash reporter is somewhat CPU intense
Infinoid the test is too timing-dependent. if there's a way to detect directly whether alarm events have fired, we should do that instead 05:07
I'm thinking the three callback functions should add 4, 2, and 1 to a global variable or something
tetragon It looks like it may also be possible to trigger a test 5 failure using the same technique 05:08
But it doesn't look likely in practice 05:09
Infinoid that's a much closer shave 05:10
tetragon For that I'd probably have to drop a prebuilt parrot tree onto my Pentium 100 05:11
And try the test while loading the system down 05:12
Infinoid 10 years ago, it would have amused me to think of a P100 as a pathological case 05:13
tetragon Well, I don't have any of my older gear anymore 05:14
And the P100 performs much better than my P3-based laptop
And I don't have a cross-compiler to get my router thrashing 05:16
(although, I think the router is more powerful than the P100) 05:17
Infinoid yeah, most embedded stuff is faster than that these days
slowest machines I have around here are some 266MHz ppc boxes and 533MHz ARM boards
tetragon My actual slowest is probably the Compaq handheld with WinCE 05:18
Infinoid I can't figure out how to declare a global variable in pir
tetragon Are there general purpose registers that you could poke? 05:22
Actually, it looks like there are instructions in docs/imcc/imcfaq.pod 05:25
Infinoid I think PIR is reallocating registers internally to prevent subroutines from clobbering eachother
(which is exactly what I want, in this case)
tetragon I'm more used to dealing with real hardware than vms
Infinoid me too 05:26
dalek r27202 | chromatic++ | trunk: 05:37
: [GC] Prevented freed contexts from appearing on the free context list multiple
: times. This works around a double-free error during global destruction exposed
: by the Rakudo fakecutable. I suspect the real problem is the interaction of
: context sharing between certain PMCs (continuations, return continuations, and
: closures) and forced context recycling. For now, we avoid the crash, until we
: debug and fix the wider problem.
diff: www.parrotvm.org/svn/parrot/revision?rev=27202
Infinoid ooh, I've got it figured out 05:38
dalek r27203 | chromatic++ | trunk: 05:43
: [src] Removed unnecessary keyword "struct" from Parrot_Context in declarations.
diff: www.parrotvm.org/svn/parrot/revision?rev=27203
nopaste "Infinoid" at 75.32.77.88 pasted "This should make the test a lot faster, and more stable under load." (68 lines) at nopaste.snit.ch/12836 05:44
Infinoid seems rock solid here for loadavg=0 and loadavg=15 05:48
(loadavg=15 takes 20 seconds to execute, but it still prints the right number.) 05:49
05:51 Zaba joined
dalek r27204 | chromatic++ | trunk: 06:01
: [include] Reverted the broken part of r27203. Oops.
diff: www.parrotvm.org/svn/parrot/revision?rev=27204
Infinoid in fact, I'm going to check this in and see if anyone complains. 06:02
dalek r27205 | infinoid++ | trunk: 06:10
: [t] Fix an intermittant failure that's been around forever.
: The "three alarms" test in t/dynoplibs/myops.t has a race condition.
: When run on a machine with a high loadavg (I used loadavg=15 for my
: tests), the "main" subroutine doesn't even get around to queueing the
: later alarms before the former ones have already fired. This results in
: the output statements occurring out of order, which fails the test.
: Since the order of these things' execution is not guaranteed,
: particularly under high load when there are significant delays just
: queueing the things, the test shouldn't depend on their order. Fix
: the test so that each callback sets 1 bit of a "flags" integer, all we
: care about is that the callbacks were actually called.
diff: www.parrotvm.org/svn/parrot/revision?rev=27205
Infinoid tetragon++ # thanks for testing and discussion 06:12
goodnight.
06:12 teknomunk joined 07:45 iblechbot joined 08:08 Zaba_ joined
dalek r27206 | fperrad++ | trunk: 08:34
: [inno]
: - collect some DLL for setup
diff: www.parrotvm.org/svn/parrot/revision?rev=27206
08:36 Zaba joined 08:37 teknomunk joined 09:20 jan joined 09:51 slightlyoff joined 10:00 jan joined 10:03 Ivatar joined 11:00 barney joined
dalek r27207 | bernhard++ | trunk: 11:04
: [Eclectus]
: clean up stst.pir
diff: www.parrotvm.org/svn/parrot/revision?rev=27207
r27208 | bernhard++ | trunk: 11:17
: Parrot built under Kubuntu 8.04
diff: www.parrotvm.org/svn/parrot/revision?rev=27208
11:46 mire joined 12:10 Zaba_ joined
dalek allison@perl.org | Concurrency Tasks: 12:54
link: www.perlfoundation.org/parrot/index...ency_tasks
shorten dalek's url is at xrl.us/bjqpy
dalek allison@perl.org | Concurrency Tasks: 12:57
link: www.perlfoundation.org/parrot/index...ency_tasks
shorten dalek's url is at xrl.us/bjqpy
dalek allison@perl.org | Concurrency Tasks:
link: www.perlfoundation.org/parrot/index...ency_tasks
shorten dalek's url is at xrl.us/bjqpy
Coke shorten, wise up. 13:56
davidfetter checkety-check yourself before you shorten yourself ;) 13:58
davidfetter wonders how shorten might most easily acquire this wisdom
14:06 jan joined
Infinoid at least its smart enough to recognise the same link over and over and reuse the existing entry 14:07
the quick way to shut it up would be to get dalek to shorten the URL itself. but I kinda like seeing the wikipage name too 14:09
14:16 jan_ joined
Coke smarter would be "you just shortened that in this channel, don't bother doing it again for N minutes." 14:37
Infinoid the same could be said of dalek, s/shortened/announced/ 14:41
15:37 ambs joined 16:03 rblackwe joined
ewilhelm Infinoid: how about a redirecting namespace for the wiki links? 16:11
e.g. somewhere.short/concurrency_tasks 16:12
of course, the title of the wiki page is already on the previous line, so you don't lose much by just having dalek say an xrl 16:13
Infinoid that would work too 16:24
it seems like dalek's svn URLs are just under the threshold of shortening, and the blog links are just over 16:25
16:55 Andy joined 17:01 ambs joined
Infinoid Coke: ping 17:08
cognominal pdump gives mie a bus error on my macbook intel 17:14
dalek r27209 | infinoid++ | trunk: 17:20
: [pdump] Fix const warnings. Add a default case to a switch statement.
diff: www.parrotvm.org/svn/parrot/revision?rev=27209
r27210 | infinoid++ | trunk: 17:23
: [pdump] Add some necessary header file dependencies to build pdump.o
: for when parrot itself hasn't been built yet. (This helps -j.)
diff: www.parrotvm.org/svn/parrot/revision?rev=27210
17:34 Andy left, Andy joined
dalek r27211 | infinoid++ | trunk: 17:39
: [pbc_info] Add some necessary header file dependencies to build pbc_info.o
: for when parrot itself hasn't been built yet. (This helps -j.)
diff: www.parrotvm.org/svn/parrot/revision?rev=27211
17:48 Theory joined
tetragon I haven't noticed anything unusual yet on my iBook (r27210, with patches for backtraces, readline detection, and architecture flags) 17:49
Infinoid was the asterisk-length stuff in printf("%*s", length, str) part of C89, added by C99, or what? 17:51
dalek r27212 | infinoid++ | trunk: 17:54
: [pbc_info] Fix a couple of 64-bit integer conversion warnings.
diff: www.parrotvm.org/svn/parrot/revision?rev=27212
r27213 | infinoid++ | trunk: 17:56
: [pdb] Fix up some const warnings.
diff: www.parrotvm.org/svn/parrot/revision?rev=27213
r27214 | infinoid++ | trunk: 18:01
: [src] Fix two warnings in src/packdump.c:
: src/packdump.c:164: warning: request for implicit conversion from 'DPOINTER *' to 'struct PMC *' not permitted in C++
: src/packdump.c:169: warning: request for implicit conversion from 'DPOINTER *' to 'struct PMC *' not permitted in C++
diff: www.parrotvm.org/svn/parrot/revision?rev=27214
Infinoid cognominal: is a backtrace available? 18:03
dalek r27215 | bernhard++ | trunk: 18:11
: [Eclectus]
: Actually use the sub scheme_entry(), as generated from NQP.
: Some tests are passing.
diff: www.parrotvm.org/svn/parrot/revision?rev=27215
particl1 fears nopaste.snit.ch/12836 won't work on platforms that don't support sub-second sleep times (like win32) 18:12
PerlJam Infinoid: the * in printf has been there for as long as I can remember, so it was probably C89 or ever K&R
particle wanders off to dig a trench & 18:13
Infinoid test results are welcome. :)
PerlJam poor particle ... it sounds like he's got latrine duty :)
Infinoid but if sleep 0.1 doesn't do anything, the test will just spin for a moment, it still shouldn't fail 18:14
hmm. guess that depends on how fast it spins
18:17 davidfetter joined
Infinoid particle: I ended up applying that diff. if it does fail on win32, I can fix it by switching from a loop-count-based loop to a time-based loop 18:18
...or just increasing the sleep time back to 1 second again. 18:20
18:23 AndyA joined 18:28 cotto_home joined 18:33 markus joined
dalek r27216 | infinoid++ | trunk: 18:35
: [pmc]
: * PMC_pmc_val(pmc) already has a return type of PMC *.
: * That means (PMC *) casts serve no purpose... remove a bunch of those.
: * Fix a minor typo in the POD, while I'm at it.
diff: www.parrotvm.org/svn/parrot/revision?rev=27216
Infinoid cognominal: thanks 18:47
cognominal you are welcome
I forgot to say I used the most recent svn parrot 18:48
Infinoid is your gdb still open? 18:49
I'm curious about the value of "cstr" at the time of the crash (src/spf_vtable.c line 320) 18:50
its either a bogus string or a bogus va_list, and a string problem would be easier to debug :)
cognominal yes 18:52
Infinoid what does "print cstr" give you?
18:52 Zaba_ joined
cognominal ) p cstr 18:52
$1 = 0x0
Infinoid all right, now we're getting somewhere :) 18:55
18:56 guru joined
Infinoid what platform? 18:56
oh, macbook intel
can you go "up" to level #5 (PackFile_Constant_dump) and print self->u.string->strstart ? 18:57
(I love the /* TODO: Won't do anything reasonable for most encodings */ comment just before this line) 18:58
cognominal 0x0 18:59
Infinoid ok, so what you've got there is a string PMC with no string pointer 19:00
cognominal I installed an hardy hearon on a virtual machine, I can see if I get the same result
I have icu btw on macosx
Infinoid ok. pdump runs fine for me on linux/amd64 19:01
cognominal compiling parrot on ubuntu
tetragon I'm haven't been having any problems on OS X 10.5 on ppc
Infinoid this crash is very likely to be dependent on the .pbc file you dumped
I tested with: ./pdump pbc_to_exe.pbc
which pbc did you use?
cognominal the same one
Infinoid ok. I'm not having any problems with ICU on linux 19:02
tetragon Just got a bus error
Infinoid tetragon: running the same thing? 19:03
tetragon Yes
cognominal I get the same problem on hardy heron 19:04
Infinoid tests linux/i686 (gentoo)
cognominal ... at the very same place 19:05
Infinoid hmm, my i686 box gets a segfault much later in the dumping process 19:06
cognominal I skipped stuff in my dump
Infinoid oh. #32, same place then 19:07
have I mentioned that this code is on my list of things to replace? :)
tetragon My one crashed part of the way through #32
cognominal so you are set
Infinoid uh. now its crashing on amd64 too. 19:08
cognominal: you infected me! :P
19:08 shamu joined
Infinoid wonders what he did differently this time 19:08
cognominal yea, I am part of the people that ruin experiments just by running around physically or virtually
Infinoid cognominal++ # scaring up the bugs 19:10
pdump has crashed in this spot for at least one month now 19:14
cognominal I think nobody used pdump for a while 19:16
Infinoid Coke: plz go back in time and fix the Makefile back then, so I can use -j8 for bisecting at arbitrary points in the past, kthx 19:17
desertm4x hey, I'm currently working on #45015 and I was wondering, if anyone could take a quick look at my code. I'd like to know, if I can go on like that. :-) (it's at stud3.tuwien.ac.at/~e0625243/parrot/tmp/ btw)
Infinoid desertm4x: at first glance, it looks reasonable 19:20
19:23 Ademan joined
desertm4x okay, that's good. thanks for taking a look at it. 19:24
Infinoid of course, the ultimate test is whether it works :)
s/reasonable/rational/ 19:26
19:27 tetragon joined 19:29 Limbic_Region joined 19:35 shamu joined 19:36 shamu left 19:40 particle joined 20:11 Zaba joined 20:25 paco joined 20:27 shamu joined 21:00 Theory joined 21:14 jmcadams joined
Coke Infinoid: time machine, check. 21:48
22:01 bgeron joined 22:35 grim_fandango joined 23:05 kid51 joined 23:30 gryphon joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!