Hi! This is the ezmlm program. I'm managing the
dev perl.apache.org mailing list.
Messages to you from the dev mailing list seem to
have been bouncing. I've attached a copy of the first
bounce
message I received.
If this message bounces too, I will send you a probe. If the
probe bounces,
I will remove your address from the dev mailing list,
without further notice.
I've kept a list of which messages from the dev mailing list
have
bounced from your address.
Copies of these messages may be in the archive.
To retrieve a set of messages 123-145 (a maximum of 100 per
request),
send a short message to:
<dev-get.123_145perl.apache.org>
To receive a subject and author list for the last 100 or so
messages,
send a short message to:
<dev-indexperl.apache.org>
Here are the message numbers:
12178
12179
12180
12181
12182
12183
12195
12196
12197
12198
12199
12200
--- Enclosed is a copy of the bounce message I received.
Return-Path: <>
Received: (qmail 42785 invoked by uid 99); 20 Apr 2007
10:13:06 -0000
Received: from herse.apache.org (HELO herse.apache.org)
(140.211.11.133)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Apr
2007 03:13:06 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
tests=SPF_HELO_PASS
X-Spam-Check-By: apache.org
Received: from [66.98.192.98] (HELO starfire.yahoo.com)
(66.98.192.98)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Apr
2007 03:12:59 -0700
Received: by starfire.yahoo.com (Postfix)
id A09C8208052; Fri, 20 Apr 2007 05:12:42 -0500 (CDT)
Date: Fri, 20 Apr 2007 05:12:42 -0500 (CDT)
From: MAILER-DAEMONyahoo.com (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
To: dev-return-12178-bond=yahoo.comperl.apache.org
Auto-Submitted: auto-replied
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=delivery-status;
boundary="7DDA9150AD4.1177063962/starfire.yahoo.com&qu
ot;
Content-Transfer-Encoding: 8bit
Message-Id: <20070420101242.A09C8208052starfire.yahoo.com>
X-Virus-Checked: Checked by ClamAV on apache.org
This is a MIME-encapsulated message.
--7DDA9150AD4.1177063962/starfire.yahoo.com
Content-Description: Notification
Content-Type: text/plain; charset=us-ascii
This is the mail system at host starfire.yahoo.com.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached
below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<bondyahoo.com>: cannot update mailbox /var/mail/bond
for user bond. error
writing message: File too large
--7DDA9150AD4.1177063962/starfire.yahoo.com
Content-Description: Delivery report
Content-Type: message/delivery-status
Reporting-MTA: dns; starfire.yahoo.com
X-Postfix-Queue-ID: 7DDA9150AD4
X-Postfix-Sender: rfc822;
dev-return-12178-bond=yahoo.comperl.apache.org
Arrival-Date: Fri, 20 Apr 2007 05:12:42 -0500 (CDT)
Final-Recipient: rfc822; bondyahoo.com
Original-Recipient: rfc822;bondyahoo.com
Action: failed
Status: 5.2.2
Diagnostic-Code: x-unix; input/output error
--7DDA9150AD4.1177063962/starfire.yahoo.com
Content-Description: Undelivered Message
Content-Type: message/rfc822
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: amavisd-new at yahoo.com
Received: from starfire.yahoo.com ([127.0.0.1])
by localhost (starfire.yahoo.com [127.0.0.1]) (amavisd-new,
port 10024)
with ESMTP id lR8NE5u5lCoW for <bondyahoo.com>;
Fri, 20 Apr 2007 05:12:35 -0500 (CDT)
Received: from mail.apache.org (hermes.apache.org
[140.211.11.2])
by starfire.yahoo.com (Postfix) with SMTP id EF7E7150A3D
for <bondyahoo.com>; Fri, 20 Apr 2007 05:12:33
-0500 (CDT)
Received: (qmail 42035 invoked by uid 500); 20 Apr 2007
10:12:35 -0000
Mailing-List: contact dev-helpperl.apache.org; run by
ezmlm
Precedence: bulk
list-help: <mailto:dev-helpperl.apache.org>
list-unsubscribe: <mailto:dev-unsubscribeperl.apache.org>
List-Post: <mailto:devperl.apache.org>
List-Id: <dev.perl.apache.org>
Delivered-To: mailing list devperl.apache.org
Received: (qmail 42024 invoked by uid 99); 20 Apr 2007
10:12:35 -0000
Received: from herse.apache.org (HELO herse.apache.org)
(140.211.11.133)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Apr
2007 03:12:35 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: local policy)
Received: from [193.30.112.121] (HELO listen.hbz-nrw.de)
(193.30.112.121)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Apr
2007 03:12:28 -0700
Received: from agrippa.hbz-nrw.de (agrippa.hbz-nrw.de
[193.30.112.24])
by listen.hbz-nrw.de (Postfix) with ESMTP id 3AC5A215F3
for <devperl.apache.org>; Fri, 20 Apr 2007 12:12:06 +0200
(CEST)
Received: from [10.1.2.40] (jansen.hbz-nrw.de
[::ffff:10.1.2.40])
by agrippa.hbz-nrw.de with ESMTP; Fri, 20 Apr 2007 12:11:39
+0200
Subject: offtopic: Embedding Perl in C++: Help needed
From: Heiko Jansen <jansenhbz-nrw.de>
To: devperl.apache.org
Content-Type: text/plain; charset=UTF-8
Organization: hbz NRW
Date: Fri, 20 Apr 2007 12:11:38 +0200
Message-Id: <1177063898.3850.86.cameltron.hbz-nrw.de>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.3
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: amavisd-new at hbz-nrw.de
X-Virus-Checked: Checked by ClamAV on apache.org
Dear *.
I´m aware that the following is not really a mod_perl
related mail but I
already posted this question elsewhere (e.g. on
perlmonks.org) without
luck and I didn't find another community with equal
knowledge about this
topic.
Feel free to answer me directly to keep this list clean.
I have to maintain a multithreaded (150+) C++ application
(running as
64Bit App on Solaris 10, SPARC, SunCC) which uses embedded
perl to allow
for easy data modification (utf-8 encoded strings) in
certain places.
This does work in general, but every now and then the
application
crashes although the same perl code has been run for a few
days.
The cores usually look similar to this stack:
-- snip --
----------------- lwp# 114 / thread# 114
--------------------
ffffffff723b0e00 Perl_sv_clear
ffffffff723b16f4 Perl_sv_free
ffffffff723a7a94 S_visit
ffffffff723a7cd8 Perl_sv_clean_objs
ffffffff7232e414 perl_destruct
ffffffff7510568c __1cHrun_sub6Fpvpc_1_
ffffffff75106434
__1cTcEmbdPerlFilterListJrunFilter6MrknKipsCString_3r1_b_
...
-- / snip --
Currently the invocation of the perl filters is implemented
as follows:
When a new (previously unencountered) perl script is to be
loaded the
following code is executed, allocating a new perl
interpreter used
solely for this script:
-- snip --
void * new_perlFilter( char * pcScriptName )
{
int _iArgc = 2;
char* _ppcArgv[] = { "", NULL, NULL };
_ppcArgv[1] = pcScriptName;
pthread_mutex_lock(&cloneMux);
PerlInterpreter * ppi = perl_alloc();
PERL_SET_CONTEXT( ppi );
perl_construct( ppi );
if( perl_parse( ppi,
xs_init,
_iArgc,
_ppcArgv,
(char **)NULL )
)
{
ppi = NULL;
}
pthread_mutex_unlock(&cloneMux);
return ppi;
}
-- / snip --
There is a global, mutex-protected list of these instances
returned by
the above function (keyed with the scripts name) and when
the
respective script is needed, the following code is executed,
calling a sub
"ips_handler" in that script (with pPi being the
interpreter instance
from the list):
char * run_sub( void * pPi, tPerlCallMap* pCallMap)
{ char* _pcRet = NULL;
try {
if(pPi) {
STRLEN _lLength = 0;
SV* _pSV = NULL;
char* _pcErg = NULL;
int _iStat = 0;
pthread_mutex_lock(&cloneMux);
PERL_SET_CONTEXT( (PerlInterpreter*)pPi );
PerlInterpreter* ppicl =
perl_clone((PerlInterpreter*)pPi,
CLONEf_COPY_STACKS);
pthread_mutex_unlock(&cloneMux);
PerlInterpreter* my_perl = ppicl;// nec. for dSP
PERL_SET_CONTEXT( my_perl );
dSP ;
ENTER ;
SAVETMPS ;
PUSHMARK(SP) ;
tPerlCallMap::iterator _oItr;
for(_oItr = pCallMap->begin();
_oItr != pCallMap->end();
_oItr++)
{
SV* _pSVIn = newSVpv(_oItr->second.c_str(), 0);
SvUTF8_on(_pSVIn);
XPUSHs(sv_2mortal(_pSVIn));
}
PUTBACK ;
_iStat = call_pv("ips_handler",
G_SCALAR | G_EVAL | G_KEEPERR);
if(_iStat) {
SPAGAIN;
_pSV = POPs;
SvUTF8_on(_pSV);
_pcErg = SvPV(_pSV, _lLength);
long _lErgLength = strlen(_pcErg);
_pcRet = new char[_lErgLength + 1];
if( _pcRet != NULL ) {
_pcRet[_lErgLength] = 0;
strcpy( _pcRet, _pcErg);
}
PUTBACK;
}
FREETMPS ;
LEAVE ;
PERL_SET_CONTEXT( my_perl );
perl_destruct( my_perl );
perl_free( my_perl );
}
}
catch(int nWhy) {}
catch(...) {}
return _pcRet;
}
I don´t see where the problem comes in.
The scripts run ok for a large number of invocations, there
is no "exit"
in it and a "die" should be catched by the G_EVAL
flag...
It even happens with perl-only scripts (i.e. no XS, only our
script,
warnings, strict, URI::Escape, and (inderectly) Carp).
Maybe it´s some concurrency problem, but I don´t get it.
Besides my missing insight in the problem I´m wondering if
there isn´t a
better approach to embedding perl:
* Using one interpreter per thread,
* with the same interpreter parsing every script the
respective
thread is told to invoke and
* invoking the scripts using a modification of the
"package
Embed::Persistent" example in `perldoc
perlembed`
This should eliminate the "perl_destruct" calls
which may trigger the
cores (although it´d increase memory consumption)?!
Any hints are welcome!
Best regards and many thanks for your help and patience
Heiko
Cologne, Germany
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeperl.apache.org
For additional commands, e-mail: dev-helpperl.apache.org
--7DDA9150AD4.1177063962/starfire.yahoo.com--
|