On 5/19/05, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Vladimir Lipsky <[EMAIL PROTECTED]> wrote:
>
> > Parrot_really_destroy needs to be fixed
>
> $verbose++ please, thanks
>
yes, please. until this issue is fixed, i'm rolling back these patches
so
At the time the main interpreter(one which has no parent) exits, there
could remain some other interpreters being run by detached threads as
in t/pmc/threads_4.pasm. To execute bytecode successfully an
interpreter needs that things like PIO, class vtables, event loop,
class_count_mutex, interpr
Nested packfile segments of type directory are freed twice by
default_destroy(). The first time it happens in directory_destroy(), and the
second time in PackFile_Segment_destroy(). This behavior is, of course,
incorrect, the patch fixes it.
packfile.c.patch
Description: Binary data
This patch prevents from an attempt to add a NULL PMC_EXT structure to the
pmc ext pool while in dod sweep run.
dod.c.patch
Description: Binary data
class_count_mutex is used without having been initialized. The fixes that.
inter_create.c.patch
Description: Binary data
The patch fixes the bug which appeared in revision 7950
mmd.c.patch
Description: Binary data
I notice that building with Perl 5.6.1 (on Win32 with Perl 5.6.1
ActiveState-build 635 and MinGW) causes problem.
$ parrot
Assertion failed: (int)io->image->bufused >= 0, file src/pmc_freeze.c,
line 478
abnormal program termination
This assertion occurs in parrot_get_config_string().
The data p
jerry gay <[EMAIL PROTECTED]> wrote:
much better! one failing test now...
D:\usr\local\parrot-HEAD\trunk>perl t/harness t/pmc/threads.t
t/pmc/threadsok 3/11# Failed test (t/pmc/threads.t at line
163)
# got: 'start 1
# in thread
# done
# Can't spawn ".\parrot.exe
"D:\usr\local\pa
As stated already, this (and possibly other thread) test(s) can't succeed
as long as Win32 has no event loop that passes the terminate event on to
the running interpreter.
1) Why the heck
--- parrot/config/gen/platform/win32/threads.h Mon May 2 14:40:59 2005
+++ parrot-devel/config/gen/platform/win
As stated already, this (and possibly other thread) test(s) can't
succeed as long as Win32 has no event loop that passes the terminate
event on to the running interpreter.
If you read the output that Jerry sent earlier, you would have seen
that the thread doesn't ever reach to the print"thread\n
parrot (r8016): no change. hangs w/98% cpu. here's the -t output:
parrot -t test_b.pasm
0 find_global P5, "_foo" - P5=SArray=PMC(0x7d5a50),
3 new P2, 18 - P2=PMCNULL,
6 find_method P0, P2, "thread3"- P0=PMCNULL,
P2=ParrotThread=PMC(0x7d5a08),
10 new P6, 54 - P6=PMCN
the 'detatch' threads test hangs on win32. this small patch skips one
Could you try the following code('the detatch' threads test with one tweak)
and tell me if it hangs either and what output you get?
find_global P5, "_foo"
new P2, .ParrotThread
find_method P0, P2, "thread3"
new P6, .TQueue # ne
And on the third hand, if I understood the code correctly ...
src/threads.c: 40: thread_func()
src/threads.c: 53: interpreter->thread_data->state |=
THREAD_STATE_FINISHED;
src/threads.c: 312: pt_thread_join ()
src/threads.c: 321: if (interpreter->thread_data->state ==
THREAD_STATE_JOINABLE ||
sr
threads_4 is testing killing threads. This is achieved by scheduling a
terminate event to the running interpreter. This can only succeed, if the
event system is running too.
see src/events.c/Parrot_new_terinate_event()
Though thr_windows.h doesn't contain error checking for now, it luckily
fails
This patch defines Win32 thread primitives. Actually it consists of the
following files:
threads.h.diff
thr_windows.h.diff
threads.t.diff
timer.t.diff
The patch had been applied, I mananged to pass all the tests from
t/pmc/thread.reast and t/pmc/timer.t but thread_4.pasm(don't know yet why it
f
> 3) Is there someone on the develpment team who could hold my hand in the
> beginning to get me going with Parrot in Visual Studio? After a brief
There isn't a certain someone. Just put your question on the list. Surely it
won't remain unaswered for long, at least as regards the
"configuring&mak
From: "Goplat" <[EMAIL PROTECTED]>
> If you really need FILE_SHARE_DELETE that badly, the check would have to
be
> done at runtime. I don't think it's all that necessary though... in fact
perl
> 5 only uses FILE_SHARE_READ, and that only if the file's not opened for
write/append.
What's more, a v
From: "Goplat" <[EMAIL PROTECTED]>
> --- Vladimir Lipsky <[EMAIL PROTECTED]> wrote:
> > From: "Goplat" <[EMAIL PROTECTED]>
> >
> > > flags_to_win32 sets fdwShareMode to FILE_SHARE_DELETE, which is not
> > > supported in wi
From: "Vladimir Lipsky" <[EMAIL PROTECTED]>
> A fix for that should be windows version specific and needs support of the
> config subsystem.
And 0f course in io_win32.c
*fdwShareMode = PIO_WIN32_SHARE_MODE;
> 0x4C56
0x4C56
From: "Goplat" <[EMAIL PROTECTED]>
> flags_to_win32 sets fdwShareMode to FILE_SHARE_DELETE, which is not
supported
> in win98 and will cause the CreateFile to fail, so the ParrotIO is NULL,
and
A fix for that should be windows version specific and needs support of the
config subsystem.
The logic
> From: "Leopold Toetsch" <[EMAIL PROTECTED]>
> Seems that we got a problem on alphas then. I can see several solutions
> to accomodate such CPUs:
>From my point of view, these solutions have the following merits and
demerits:
> - use only PMCs that don't cross cache lines
+) No need for memory
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
> That isn't necessary. One rmb() after resetting C ought to be
> enough. It ensures that in all cases the other CPU reads str_val as
> NULL. If the vtable is still pointing to the PerlInt vtable, its a user
Having an only rmb() on the writing CPU hardl
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
> Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> > On Friday, January 30, 2004, at 11:52 , Leopold Toetsch wrote:
> >> + /*
> >> + * if we morph to a string, first clear str_val
> >> + * so that after changing the vtable a parallel
>
Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> On Friday, January 30, 2004, at 11:52 , Leopold Toetsch wrote:
>> + /*
>> + * if we morph to a string, first clear str_val
>> + * so that after changing the vtable a parallel
>> + * reader doesn't get a gargabe pointer
>> +
Well, there is always up-to-date documentation, your debugger output ...
0x4C56
Who says that the copy-paste antipattern is bad?
0x4C56
- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
To: "Vladimir Lipsky" <[EMAIL PROTECTED]>
Cc: "perl6-internals" <[EMAIL PROTECTED]>
Sent: Wednesday, December 31, 2003 10:49 PM
Subject: Re: More Windows dev ques
From: "Dan Sugalski" <[EMAIL PROTECTED]>
> On a Unix system, a core dump is a file with a raw (mostly) copy of a
> process' current memory image that's written whenever a process does
> something profoundly illegal, like accessing an inaccessible section
> of memory with no trap handler that allow
From: "Jonathan Worthington" <[EMAIL PROTECTED]>
> Here is my attempt at a patch for executable memory allocation, which
makes
+void *
+mem_alloc_executable(size_t size)
+{
+ void *ptr = VirtualAlloc(NULL, size, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
^^^
And a note for 3): It's importatnt to create a thread with CREATE_SUSPENDED,
and at thread runtime we have to suspend thread while checking out its
registers so that to get the true values.
SuspendThread(thdl);
GetThreadContext(thdl, &ctx);
...
ResumeThread(thdl);
0x4C56
From: "Dan Sugalski" <[EMAIL PROTECTED]>
> So, could someone with some windows experience go digging and find
> out how one would:
>
> 1) Find the address of the base of a thread's stack
> 3) Find out what a thread's current stack pointer is
I would do 1), 3) this way ...
thdl = _beginthreadex
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
> Vladimir Lipsky <[EMAIL PROTECTED]> wrote:
> >> Ah, that's the reason for your bug report WRT JIT/NCI. The question is,
> >> how can we detect the presence of the exec-shield patch. Your
`uname -a`
&
> Ah, that's the reason for your bug report WRT JIT/NCI. The question is,
> how can we detect the presence of the exec-shield patch. Your `uname -a`
> doesn't indicate it.
What for? We just always do allocating memory from a JIT dedicated heap with
execute flas set on it, no matter the presence of
Beware :) This patch changes Parrot_loadbc to Parrot_set_packfile.
0x4C56
diff
Description: Binary data
From: "Dan Sugalski" <[EMAIL PROTECTED]>
> At 2:01 PM +0100 12/14/03, Leopold Toetsch wrote:
> >Can we use this lib:
> >http://sources.redhat.com/pthreads-win32/
> >distributed under the GNU Lesser General Public License
(LGPL)
>
> I think so, yes. I'd rather use windows native threading if we can
From: "Melvin Smith" <[EMAIL PROTECTED]>
> At 04:20 PM 12/9/2003 -0500, Dan Sugalski wrote:
> >which is .included) and visible through the rest of the compilation unit.
> >
> Parser will not allow .const outside of a compilation unit and make it
> global to the
> compilation.
Hmm... What do you
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
> Did you recheck that after my fix to vtable freeing? My patch covered
> encoding and chartype too.
No, I didn't. Did you fix the Parrot_loadbc function name? If didn't, I'll
have a go for Parrot_set_PackFile()
> leo
0x4C56
Happy
.~.
Some time ago I mentioned I'd been gettin' one more segfault while the
Parrot
debug mode was on. In fact, it proved to be an effect of the same cause --
we
have global resources sharable among interpreters, that we try to free more
than
once. This time it's encoding_array. If you're going to disabl
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
Sent: Wednesday, December 03, 2003 12:05 PM
> The bug is already fixed. But we have to separate interpreter globals
> and real globals finally. Some time ago, I suggested to change the init
> functions slightly to take a parent interpreter argument:
Do
From: "Dan Sugalski" <[EMAIL PROTECTED]>
Sent: Tuesday, December 02, 2003 5:27 PM
> Well, bah. I'll disable the table freeing for now and that should
> take care of the bug at the moment, though it certainly won't cure
> the underlying memory leak.
>
> Arguably, and this is getting into the rea
Have a look at the following code fragment
Parrot_PackFile pf;
char *bc = "file.pbc";
pf = Parrot_readbc(interpreter, bc);
Parrot_loadbc(interpreter, pf);
Did you catch the difference between the 2nd actual parameter and
the function name? Maybe it's worth renaming? E.g. Parrot_loadpf()
0x4C56
From: "Dan Sugalski" <[EMAIL PROTECTED]>
Sent: Monday, December 01, 2003 9:53 PM
> *) I've made the Parrot_base_vtable array movable again, as it needs
> to be resized. This is a temporary hack, since there are horrible
> threading issues here. (Not to mention the fact that this table is
> glob
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
Sent: Monday, December 01, 2003 5:47 PM
>Which child interpreter? Parrot_destroy_vtable() is called after
>free_unused_pobjects().
Okay. I'll try to reword the problem all over again.
Well you know test 61 in t/pmc/pmc.t causes a segfault. To get thing
> > t\pmc\pmc...NOK 62# Failed test (t\pmc\pmc.t at line
1497)
> > # got: 'All names and ids ok.
> > # Can't spawn ".\parrot.exe --gc-debug -b t\pmc\pmc_62.pasm": Bad file
> > descripto
> > r at lib/Parrot/Test.pm line 62.
>
> I've no clue, what's going on here. Does the te
From: "Leopold Toetsch" <[EMAIL PROTECTED]>
Sent: Thursday, November 27, 2003 12:04 PM
> PMC (in gdb speak):
> b dod.c:525
> r t/pmc/pmc_61.pasm
> p *(PMC *) b
> p *((PMC *) b)->vtable
> c
> ...
Umm .. the problem is that this pmc doesn't have the vtable;
(*((PMC *)b)).vtable points t
Well, currently, test 61 in t/pmc/pmc.t causes an abrupt stop of
the test session with the segfault box popping up. I haven't yet
taken a time to figure out what actually is the cause of trouble,
but I've already detected the precise place where that all happens.
It happens here
void
free_unused_
> At Wed, 26 Nov 2003 05:20:50 +0300,
> Vladimir Lipsky wrote:
> >
> > If it blocks the automated test builds, then just turning the box off is
> > okay. It must be admitted that, the truth is that I don't know anybody
> > who does send those reports
>
> M
If it blocks the automated test builds, then just turning the box off is
okay. It must be admitted that, the truth is that I don't know anybody
who does send those reports
0x4C56
- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November
> Currently it isn't prohibitied. That is the only way to detect an error
> from PIO_open* at this time.
io = PIO_open(interpreter, NULL, file[i], flags[j]);
if ( (PIO_eof(interpreter, io) ? 0:1) != expected[i][j] )
{
0x4c56
Hey unix folks, does test 10 in t/src/io.t succed on your OS?
0x4c56
io_win32.diff
Description: Binary data
Hi everyone!
In t/src/io.c, specifically test 9 and 10, I wonder if the PIO_eof check up
works anywhere; because I didn't manage to find any place where the
PIO_F_EOF flag is set up when the PIO_*_open function fails neither
in io_stdio.c, io_unix.c nor io_win32.c
Is the "io == NULL" testing proh
D:\build\parrot>nmake
...
d:\build\parrot\src\encoding.c(39) : warning C4090: 'function' : different
'const' qualifiers
d:\build\parrot\src\encoding.c(39) : warning C4022: 'mem_sys_free' : pointer
mismatch for actual parameter 1
...
d:\build\parrot\src\chartype.c(231) : warning C4090: 'function' :
51 matches
Mail list logo