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 the threads test 6 is again skipped on windows
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,
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
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
The patch fixes the bug which appeared in revision 7950
mmd.c.patch
Description: Binary data
class_count_mutex is used without having been initialized. The fixes that.
inter_create.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
jerry gay [EMAIL PROTECTED] wrote:
much better! one failing test now...
D:\usr\local\parrot-HEAD\trunkperl 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
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 printthread\n
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 (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 -
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 # need
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
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 ||
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
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
configuringmaking
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 is
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]
--- Vladimir Lipsky [EMAIL PROTECTED] wrote:
From: Goplat [EMAIL PROTECTED]
flags_to_win32 sets fdwShareMode to FILE_SHARE_DELETE, which is not
supported in win98
A fix for that should be windows version specific and needs support of
the
config
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 value
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
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
+ */
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
+ * reader
Well, there is always up-to-date documentation, your debugger output ...
0x4C56
Who says that the copy-paste antipattern is bad?
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 allows
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 questions: Core dumps
At 11:51 PM +0300 12/31/03, Vladimir Lipsky
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(NULL,
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: 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);
^^^
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
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`
doesn't indicate it.
What for? We just always do allocating
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/
citedistributed under the GNU Lesser General Public License
(LGPL)/cite
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 mean by a
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
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: 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 you
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 realm of
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 to a block
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 test-file exist
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 things
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
global and
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
More important -- is the Segfault reported in any other
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
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
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 25,
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
D:\build\parrotnmake
...
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' :
48 matches
Mail list logo
