I'm writing an extension that uses Google's V8 engine. I'm getting a
segfault after my module has been unloaded.
Here is what I get when running PHP:
DYLD_PRINT_LIBRARIES_POST_LAUNCH=1 /phpdev/bin/php -f
/Server/www/localhost/test.php
dyld: loaded: /phpdev/lib/php/extensions/debug-zts-20090626/v8
> I'm using the line:
>
> PHP_ADD_LIBRARY_WITH_PATH(v8, $V8_DIR/$PHP_LIBDIR, V8PHP_SHARED_LIBADD)
>
> Where the path is /phpdev/lib. But my extension is actually linking to
> /v8/out/x64.release/libv8.dylib instead of /phpdev/lib/libv8.dylib even though
> /v8/out/x64.release no longer exists.
>
On Apr 11, 2012, at 12:02 PM, Chris Stockton wrote:
> Hello,
>
> On Wed, Apr 11, 2012 at 11:47 AM, Luke Scott wrote:
>>
>> The .php extension really isn't used by PHP, but it's used by a web server
>> to identify PHP code and send it to the interpreter. Any
On 4/11/12 11:27 AM, "Chris Stockton" wrote:
>Hello,
>
>On Wed, Apr 11, 2012 at 11:14 AM, Tom Boutell wrote:
>> On Wed, Apr 11, 2012 at 1:48 PM, Chris Stockton
>> wrote:
>>> I have read the RFC and I although from what I gather it seems that
>>> .phpp is a recommendation and not a requirement,
bc on that one! I have been
programming for 10 years and that one still confuses me! Most people
just add parentheses to "fix" the problem. I wish someone would write
an RFC to change this to right associative like every other language!
*hint hint*
Luke Scott
On Apr 10, 2012, at 9:2
Hey Rasmus,
Here are my thoughts:
On Apr 11, 2012, at 7:09 AM, Rasmus Lerdorf wrote:
> On 04/11/2012 12:59 AM, Stas Malyshev wrote:
>>> Therefore, it should not be misunderstood as perfect LFI
>>> countermeasure even if I stressed on security meanings.
>>> I'm stressing security because this ac
On Apr 10, 2012, at 6:59 PM, Tom Boutell wrote:
> On Tue, Apr 10, 2012 at 8:19 PM, Luke Scott wrote:
>> - I would like to see an INCLUDE_SILENT method to prevent warnings from
>> being thrown with include/include_once statements. Currently doing
>> something like @inclu
On 4/10/12 4:53 PM, "Tom Boutell" wrote:
>Please see:
>
>https://wiki.php.net/rfc/source_files_without_opening_tag
>
>After following the discussion I have updated the RFC with the
>following major changes:
>
>* Forbade the use of ?> entirely in "pure PHP" files (without
>restricting it at all in
I'm using the line:
PHP_ADD_LIBRARY_WITH_PATH(v8, $V8_DIR/$PHP_LIBDIR, V8PHP_SHARED_LIBADD)
Where the path is /phpdev/lib. But my extension is actually linking to
/v8/out/x64.release/libv8.dylib instead of /phpdev/lib/libv8.dylib even
though /v8/out/x64.release no longer exists.
What am I doing
>
>> I'm writing an extension called "V8PHP". It's similar to the V8JS extension,
>> but the implementation is quite different.
>>
>> ...
>>
>> Anyone know what the problem could be?
>>
>> Luke
>
> I figured out that v8 was being compiled in 32 bit mode... Apparently it
> thinks "native" means
Tom,
On Apr 10, 2012, at 6:48 AM, Tom Boutell wrote:
> The "second part" in the RFC is just a suggested filename convention,
> it is not a hardcoded requirement. I'm not sure that's what you're
> talking about here.
>
> The RFC I'm referring to does not propose completely removing the
> availabi
On Apr 10, 2012, at 12:24 AM, Flavius Aspra wrote:
> On 04/09/2012 10:30 PM, Luke Scott wrote:
>> Yeah it would be. He also mentioned something about preloading
>> framework classes.. Would like to hear his thoughts on that!
>
> I also subscribe to the opinion of object
On Apr 9, 2012, at 10:03 PM, Yasuo Ohgaki wrote:
> I strongly discourage settingallow_url_include=on, too.
Good.
> Enabling it only when it is needed is okay.
No it's not. There is no reason to do so other than backwards
compatibility for very old code.
> I think you are concerned about secur
On Apr 9, 2012, at 9:08 PM, Yasuo Ohgaki wrote:
>> I would actually suggest that require/include stop supporting remote
>> files all together. But that can be a different RFC.
>>
>> This "security problem" isn't a problem with common sense.
>
> Requiring/Including remote file is not bad, just lik
> It's easy to say "write correct code. don't write stupid code", but
> we cannot enforce it in real world.
>
> I'm concerning both arbitrarily script execution and arbitrarily
> information disclosure. Good example is LFI and SQL injection
> attack.
Uh yeah there is. I won't employ someone who i
On Apr 9, 2012, at 8:26 PM, Yasuo Ohgaki wrote:
> Hi,
>
> 2012/4/10 Luke Scott :
>> On Apr 9, 2012, at 7:50 PM, Yasuo Ohgaki wrote:
>>
>>> Please don't repeat mistakes for allow_url_include or allow_url_include.
>>> If admin would like to enforc
On Apr 9, 2012, at 7:50 PM, Yasuo Ohgaki wrote:
> Please don't repeat mistakes for allow_url_include or allow_url_include.
> If admin would like to enforce programmer not to change php.ini.
> They should use Apache httpd and admin_flag/admin_value.
>
> Programmers should have as much control as p
On Apr 9, 2012, at 7:44 PM, Yasuo Ohgaki wrote:
> Hi,
>
> 2012/4/10 Luke Scott :
>>>>> That said, allowing the skipping of an initial >>>> the file probably wouldn't be a big deal to implement in code mode.
>>>>
>>>>
>>>&g
On Apr 9, 2012, at 6:22 PM, Kris Craig wrote:
If the default is "template mode" and the " top) in "code" mode there shouldn't be any problems.
>
> We don't need to change or leave out the tag entirely.
>
> Is there a problem with people being able to choose "template mode" or
> "code mode" as the
On Apr 9, 2012, at 6:22 PM, Tom Boutell wrote:
> On Mon, Apr 9, 2012 at 9:11 PM, Luke Scott wrote:
>> Given that an autoloader just has the class name with the attached
>> namespace, how is it to know whether or not to load a .php file or a .phpc
>> file? I'm not
>I'd totally be open to an alternative to the scrutiny, but so far I haven't seen one. And absent that, there's no way
>I
>could support this, which really sucks because at least conceptually I
>think it's a really good idea.
If the default is "template mode
On 4/9/12 5:38 PM, "Tom Boutell" wrote:
>On Mon, Apr 9, 2012 at 8:27 PM, Luke Scott wrote:
>> Tom,
>>
>> On 4/9/12 4:47 PM, "Tom Boutell" wrote:
>>
>>>Let me be very clear about that... I am NOT proposing that >>the top be manda
>
>On Mon, Apr 9, 2012 at 7:06 PM, Luke Scott wrote:
>> On 4/9/12 3:53 PM, "Tom Boutell" wrote:
>>
>>>I see why you want to allow >>mode,' rather than disallowed in code mode. But your purpose is to
>>>allow legacy code to be autoloaded wi
> I'm writing an extension called "V8PHP". It's similar to the V8JS extension,
> but the implementation is quite different.
>
> ...
>
> Anyone know what the problem could be?
>
> Luke
I figured out that v8 was being compiled in 32 bit mode... Apparently it
thinks "native" means 32 bit... Recom
> On Mon, Apr 9, 2012 at 3:34 PM, Luke Scott wrote:
>> Tom,
>>
>> On 4/9/12 3:17 PM, "Tom Boutell" wrote:
>>
>>> >My original goal was to stop typing >> >includes at the top. I think it's entirely reasonable to achieve it
>
't know about .phpc files, what are they
>anyway... google google... aha, I need PHP 5.x and an updated
>autoloader. Grumble. Okay."
>
>This is a much safer outcome.
>
>On Mon, Apr 9, 2012 at 6:34 PM, Luke Scott wrote:
>> Tom,
>>
>> On 4/9/12 3:17 PM, &qu
Tom,
On 4/9/12 3:17 PM, "Tom Boutell" wrote:
>My original goal was to stop typing includes at the top. I think it's entirely reasonable to achieve it
>with an option to the require keywords for this purpose and a naming
>convention to be followed by autoloaders. Keep in mind how rarely you
>have
I'm writing an extension called "V8PHP". It's similar to the V8JS extension,
but the implementation is quite different.
I'm having trouble linking the v8 library to my extension. When I run a PHP
script via CLI I get:
dyld: lazy symbol binding failed: Symbol not found: __ZN2v86String3NewEPKci
> Obviously, it would need to be at the top of the PHP file (whitespace
> notwithstanding). Since we don't want any BC breaks, we at very least need
> it to start with " mean to be parsed. So how about we keep it simple and just use a single,
> " would be allowed after that.
> Anything before tha
Pierre,
On Apr 7, 2012, at 11:14 AM, Pierre Joye wrote:
> Something I have been discussed in the past with a couple of persons
> is to have a mechanism to automatically instantiate objects on request
> start. That's not persistent objects but that could already boost a
> little it the base foot
On Apr 9, 2012, at 7:49 AM, Flavius Aspra wrote:
> On 04/07/2012 05:21 AM, Luke Scott wrote:
>> From what I've gathered thus far, it is impossible to do without copying the
>>
>> non-persistent memory into persistent memory, and then back again.
>
> Hi, glad to
on include/require with APC, with file_exists you cannot.
Perhaps that belongs in a different RFC... But if we're thinking of
using constants it would be a nice thing to mention.
Luke
>
> On Mon, Apr 9, 2012 at 1:51 PM, Luke Scott wrote:
>> On Apr 9, 2012, at 10:44 AM, Ralph Schi
On Apr 9, 2012, at 12:16 PM, "Ángel González" wrote:
> On 09/04/12 20:23, Chris Stockton wrote:
>> Hello,
>> Although I am not very interested in this feature, if it is
>> implemented I like the idea of flags instead of introducing new
>> keywords. Maintaining backwards compatibility would be gre
On Apr 9, 2012, at 12:27 PM, "Ángel González" wrote:
> On 09/04/12 19:36, Luke Scott wrote:
>> On Apr 9, 2012, at 10:23 AM, Tom Boutell wrote:
>>> Also, your objection - that 'require_code' is confusing - would most
>>> likely be an issue for a han
>>> I see what you're saying, but you're proposing a new keyword to
>>> include code that does what plain old 'require' does now (assuming
>>> it's not a nice clean class file that is being included). Which means
>>> that valid code toda
now (assuming
>> it's not a nice clean class file that is being included). Which means
>> that valid code today is busted code once this feature comes out. That
>> seems like a very hard sell.
>>
>> On Mon, Apr 9, 2012 at 1:10 PM, Luke Scott wrote:
>>> On
as adding a keyword as it is what keyword you're adding.
I hope the way I've explained things makes sense.
Luke
>
> On Mon, Apr 9, 2012 at 11:43 AM, Luke Scott wrote:
>> Tom,
>>
>> As I've said before I don't think new keywords are the answer. They
>&
Tom,
As I've said before I don't think new keywords are the answer. They
will just pollute the language even further.
I also don't think an ini setting is a bad thing either. It is often
used in PHP as a way to transition from way of doing things to
another. First you introduce it with it being o
On Apr 7, 2012, at 11:14 AM, Pierre Joye wrote:
> On Sat, Apr 7, 2012 at 6:51 PM, Luke Scott wrote:
>
>> I think I understand what you're getting at. So to avoid fragmentation
>> you would have to have two independent memory spaces. Making non
>> persistent me
On Apr 7, 2012, at 9:45 AM, Pierre Joye wrote:
> hi,
>
> On Sat, Apr 7, 2012 at 4:59 PM, Luke Scott wrote:
>
>>> The expensive parts here are not the object creation on its own but to
>>> get the data they contain (external, calculation, etc.).
>>
>>
On Apr 6, 2012, at 10:41 PM, Stas Malyshev wrote:
> Hi!
>
>> How is memory tracked with emalloc? From my observations anything
>> created with emalloc, with or without a zval wrapper, is freed at the
>> end of the request. Things created with pemalloc, which seems to be a
>> wrapper of malloc, is
.
Luke
(Sorry, I keep forgetting to hit reply all)
>
> On Apr 7, 2012, at 11:46 AM, Luke Scott wrote:
>
>> On Apr 7, 2012, at 7:00 AM, Tom Boutell wrote:
>>
>>> That's a good point too.
>>>
>>> I think this is a better proposal:
>>>
&
On Apr 7, 2012, at 7:00 AM, Tom Boutell wrote:
> That's a good point too.
>
> I think this is a better proposal:
>
> ...
Tom, sorry! For some reason I thought Tony :). On my phone... Not as
intuitive as my desktop...
Luke
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
On Apr 7, 2012, at 7:00 AM, Tom Boutell wrote:
> That's a good point too.
>
> I think this is a better proposal:
>
> include_code, require_code, and require_code_once would work just like
> include, require and require_once, except that the parser would start
> out in PHP mode.
>
> .phpc is then
On Apr 7, 2012, at 5:22 AM, Pierre Joye wrote:
> hi,
>
> 2012/4/7 Luke Scott :
>
>> It would be ideal of you could initialize a bunch of objects once and
>> carry them over to the next request. No serialization, no copying. A
>> lot of framework objects would benefi
On Apr 6, 2012, at 5:23 PM, "Johannes Schlüter" wrote:
> Hi,
>
> On Fri, 2012-04-06 at 16:46 -0700, Luke Scott wrote:
>>
>>
>> From what I've gathered thus far, it is impossible to do without
>> copying the non-persistent memory into persistent m
On Apr 6, 2012, at 5:16 PM, Stas Malyshev wrote:
Hi!
>From what I've gathered thus far, it is impossible to do without copying the
non-persistent memory into persistent memory, and then back again. I'm
assuming this is because all the memory associated with PHP variables use
emalloc, which p
I've spent the last few days pouring over the Zend engine source code. I
think I have a basic understanding on the memory management. Likely what I
say may be incorrect, so I apologize in advance.
What I'm trying to do is write an extension to persist PHP variables past
the end of the request in t
48 matches
Mail list logo
