Menu
▾
▴
ming-devr — a list for ming developers and those interested in ming's guts
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(10) |
Sep
(6) |
Oct
|
Nov
(42) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(4) |
Feb
(17) |
Mar
(8) |
Apr
(9) |
May
(12) |
Jun
(28) |
Jul
(8) |
Aug
(8) |
Sep
(15) |
Oct
(21) |
Nov
(39) |
Dec
(13) |
| 2004 |
Jan
(128) |
Feb
(32) |
Mar
(46) |
Apr
(98) |
May
(51) |
Jun
(26) |
Jul
(54) |
Aug
(16) |
Sep
(45) |
Oct
(71) |
Nov
(12) |
Dec
(9) |
| 2005 |
Jan
|
Feb
(4) |
Mar
(57) |
Apr
(37) |
May
(11) |
Jun
(5) |
Jul
(14) |
Aug
(65) |
Sep
(16) |
Oct
(2) |
Nov
(36) |
Dec
(21) |
| 2006 |
Jan
(79) |
Feb
(81) |
Mar
(15) |
Apr
(60) |
May
(56) |
Jun
(26) |
Jul
(12) |
Aug
(3) |
Sep
(3) |
Oct
(2) |
Nov
(20) |
Dec
(114) |
| 2007 |
Jan
(45) |
Feb
(15) |
Mar
(3) |
Apr
(12) |
May
(6) |
Jun
(14) |
Jul
(8) |
Aug
|
Sep
(14) |
Oct
(5) |
Nov
(21) |
Dec
(9) |
| 2008 |
Jan
(53) |
Feb
(3) |
Mar
(5) |
Apr
(30) |
May
(40) |
Jun
(31) |
Jul
(84) |
Aug
(15) |
Sep
(56) |
Oct
(17) |
Nov
(6) |
Dec
(40) |
| 2009 |
Jan
(9) |
Feb
(11) |
Mar
(39) |
Apr
(8) |
May
(4) |
Jun
(4) |
Jul
(2) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
(15) |
Dec
(30) |
| 2010 |
Jan
(4) |
Feb
(22) |
Mar
(6) |
Apr
(6) |
May
(12) |
Jun
(21) |
Jul
(5) |
Aug
(7) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
(1) |
Feb
(4) |
Mar
(7) |
Apr
(2) |
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(11) |
Jun
(4) |
Jul
(3) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
1
|
2
(1) |
3
|
4
|
|
5
(1) |
6
|
7
|
8
(1) |
9
|
10
|
11
|
|
12
|
13
|
14
|
15
|
16
|
17
|
18
|
|
19
|
20
(1) |
21
(5) |
22
|
23
|
24
|
25
(1) |
|
26
|
27
|
28
|
29
(3) |
30
(3) |
31
(1) |
|
|
From: Yoav L. <yo...@co...> - 2008-10-31 14:41:58
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body dir="ltr" bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid:490...@re..." type="cite">I tried
the following to reproduce the crash:
<br>
<br>
<?
<br>
$m = new SWFMovie();
<br>
$file = fopen("test.as", "r");
<br>
$script = fread($file, filesize("test.as"));
<br>
$a = new SWFAction($script);
<br>
$m->add($a);
<br>
$m->save("test.swf");
<br>
?>
<br>
<br>
where test.as consists of 3000 times of
<br>
trace("test");
<br>
<br>
Could you produce a simple testcase out of the crashing code please?
<br>
<br>
Klaus
<br>
<br>
</blockquote>
<font size="-1">Hi again! <br>
<br>
Thanks for your swift reply. <br>
Perhaps I didn't explain myself correctly: <br>
The problem appears only when you create one long action script line. <br>
For instance, setting a new string variable and the string is more than
2000 characters. <br>
I used your example above, I modified the file test.as to: var
myTest:Array = new Array(); and the array I insert is very long. <br>
The reaction was:<br>
</font><b>Fatal error</b>: SWFMovie::save() [<a
href='swfmovie.save'>swfmovie.save</a>]: var myTest:Array =
new Array({type:1, x:0, y:0, w:1432, h:985,
src:&quot;opening/FrameW.swf&quot;,
imageRatio:0.687746621503649, fileType:&quot;SWF&quot;,
lockRatio:undefined, keyIn:undefined,
effectIn:&quot;undefined&quot;, keyOut:undefined,
effectOut:&quot;undefined&quot;, frameRate:undefined,
syncSwf:undefined, Size:undefined}, {type:1, x:51, y:99, w:604, h:401,
src:&quot;opening/op04.swf&quot;, imageRatio:0.33085194375517,
fileType:&quot;SWF&quot;, lockRatio:undefined,
keyIn:-0.953000000000003, effectIn:&quot;undefined&quot;,
keyOut:3.488, effectOut:&quot;undefined&quot;,
frameRate:undefined, syncSwf:undefined, Size:undefined}, {type:1, x:51,
y:99, w:908, h:605, src:&quot;opening/30-38.JPG&quot;,
imageRatio:0.666299559471366, fileType:&quot;JPG&quot;,
lockRatio:undefined, keyIn:4.063,
effectIn:&quot;undefined&quot;, keyOut:5.317,
effectOut:&quot;undefined&quot;, frameRate:undefined,
syncSwf:undefined, Size:undefined}, {type:1, x:51, y:99, w:91 in <b><br>
/root/test/bug/index.php</b> on line <b>13<br>
<small><br>
</small></b><small>As you can see the array is cut in the middle. When
I shortened it a bit everything worked fine. <br>
By the way, the problem occurred from version 0.4.0 Beta 5. <br>
<br>
Thanks a lot! <b><br>
</b>Yoav.</small><b><small> <br>
</small><br>
<br>
</b><font size="-1"><br>
<br>
<br>
<br>
</font>
</body>
</html>
|
|
From: Klaus R. <kl...@re...> - 2008-10-30 20:41:48
|
Hi,
>
> I made a ming upgrade on my server. Whenever I create an action (new
> SWFAction()) longer then 2000 characters I get :
> child pid 2608 exit signal Segmentation fault (11).
> I suspect a memory leak is causing this problem and it might be
> related to the problem discussed here.
>
I tried the following to reproduce the crash:
<?
$m = new SWFMovie();
$file = fopen("test.as", "r");
$script = fread($file, filesize("test.as"));
$a = new SWFAction($script);
$m->add($a);
$m->save("test.swf");
?>
where test.as consists of 3000 times of
trace("test");
Could you produce a simple testcase out of the crashing code please?
Klaus
|
|
From: Alan B. <abo...@ma...> - 2008-10-30 19:12:09
|
Yes Yoav, your email has been received.
Alan
Yoav Levy wrote:
> Hi,
>
>
> Yesterday I sent the message below; I am new to this newsletter,
> please let me know if I sent it correctly, thanks a lot!
>
>
> I made a ming upgrade on my server. Whenever I create an action (new
> SWFAction()) longer then 2000 characters I get :
> child pid 2608 exit signal Segmentation fault (11).
> I suspect a memory leak is causing this problem and it might be
> related to the problem discussed here.
>
> Thanks,
> Yoav
>
>
>> Absolutly,
>>
>> It's really in the php extension. I'm wondering what happen.. if the
>> object reference is properly removed for the list and the C
>> destructor is well called, where could be the problem inside the
>> extension? This could be inside php code. I don't think that
>> extensions that use the new zend api have this problem.
>>
>> Alan
>>
>> -----Original Message-----
>> From: "Klaus Rechert" <kla...@rz...>
>> Sent: Wednesday, October 29, 2008 6:00am
>> To: "Alan Boudreault" <abo...@ma...>, "Ming Developers
>> mailing list" <min...@li...>
>> Subject: Re: [Ming-dev] Memory problem with the php extension ?
>>
>> Hi,
>>
>> sorry I was mostly offline the last few days. I poked a little bit in
>> the code but haven't found a real solution yet.
>>
>> For sure is:
>> 1. ming's shape() does not leak (checked via a C testcase)
>> 2. memory usage scales with the number of instances
>>
>> I have the strong suspicion that the list holding the instances is
>> not cleared.
>>
>> Cheers
>> Klaus
>>
>>
>>> Hi Klaus,
>>>
>>> I'm wondering if you have any new about the problem ? (Can you add
>>> me in CC in the bugzilla plz)
>>>
>>> Thanks,
>>> Alan
>>>
>>> Alan Boudreault wrote:
>>>
>>>> In fact, replacing the zend_list_insert by
>>>> ZEND_REGISTER_RESOURCE........ has the same effect that removing
>>>> the zend_list_addref().
>>>>
>>>> Alan
>>>>
>>>> Klaus Rechert wrote:
>>>>
>>>>> Hi Alan,
>>>>>
>>>>> the __construct function looks like this now:
>>>>>
>>>>> PHP_METHOD(swfshape, __construct)
>>>>> {
>>>>> SWFShape shape = newSWFShape();
>>>>> int rsrc_id = ZEND_REGISTER_RESOURCE(return_value, shape,
>>>>> le_swfshapep);
>>>>> // int rsrc_id = zend_list_insert(shape, le_swfshapep);
>>>>> object_init_ex(getThis(), shape_class_entry_ptr);
>>>>> add_property_resource(getThis(), "shape", rsrc_id);
>>>>> zend_list_addref(rsrc_id);
>>>>> }
>>>>>
>>>>> Commenting the zend_list_addref() has no additional effect on
>>>>> memory usage here.
>>>>>
>>>>> Thanks
>>>>> Klaus
>>>>>
>>>>>
>>>>>> Hi Klaus,
>>>>>>
>>>>>> I was writing you a comment on bugzilla.... but still waiting the
>>>>>> account creation confirmation... here's what i wrote:
>>>>>>
>>>>>> If you comment the following line, in PHP_METHOD(swfshape,
>>>>>> __construct) method:
>>>>>> zend_list_addref(ret);
>>>>>>
>>>>>> The destructor is well called (verified with a printf in the
>>>>>> destructor). BUT, the PHP OBJECT doesn't seem to be freed by
>>>>>> php garbage collector. See what i get now:
>>>>>>
>>>>>> Beginning of script : 57368 bytes
>>>>>>
>>>>>> End of script : 769960 bytes
>>>>>>
>>>>>> So, there are still "memory leaks".
>>>>>>
>>>>>> Thanks,
>>>>>> Alan
>>>>>>
>>>>>> Klaus Rechert wrote:
>>>>>>
>>>>>>
>>>>>>> It is me again ;)
>>>>>>>
>>>>>>> Just dug a little bit in ZEND sources. Using
>>>>>>> ZEND_REGISTER_RESOURCE() instead of zend_list_insert() made the
>>>>>>> destructor function working. Running again your testcase results
>>>>>>> in:
>>>>>>>
>>>>>>> End of script : 1012316 bytes
>>>>>>>
>>>>>>> instead of
>>>>>>>
>>>>>>> End of script : 1524912 bytes for Ming 0.4.2.
>>>>>>>
>>>>>>> One little step... :)
>>>>>>>
>>>>>>> Cheers
>>>>>>> Klaus
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> just checked your example. You are right PHP leaks. I'm not
>>>>>>>> sure why... There are destructor functions defined and
>>>>>>>> registered, but not called at all.
>>>>>>>>
>>>>>>>> I filed a bug
>>>>>>>> http://bugs.libming.net/show_bug.cgi?id=74
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Klaus
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi guys, i'm wondering if you are aware of this problem using
>>>>>>>>> your extension (or in the php garbage collector) ?
>>>>>>>>>
>>>>>>>>> See my script and results: http://pastebin.ca/1231918
>>>>>>>>>
>>>>>>>>> Do you know why the memory of the php object are not freed ?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alan
>>>>>>>>>
>>>>>>>>>
>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>
>>>>>>>> This SF.Net email is sponsored by the Moblin Your Move
>>>>>>>> Developer's challenge
>>>>>>>> Build the coolest Linux based applications with Moblin SDK &
>>>>>>>> win great prizes
>>>>>>>> Grand prize is a trip for two to an Open Source event anywhere
>>>>>>>> in the world
>>>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>>>> _______________________________________________
>>>>>>>> Ming-devr mailing list
>>>>>>>> Min...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/ming-devr
>>>>>>>>
>>>>>>
>>>>
>>>
>>
>>
>>
>>
>> -------------------------------------------------------------------------
>>
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Ming-devr mailing list
>> Min...@li...
>> https://lists.sourceforge.net/lists/listinfo/ming-devr
>>
>>
>
--
Alan Boudreault
Mapgears
http://www.mapgears.com
|
|
From: Yoav L. <yo...@co...> - 2008-10-30 16:27:13
|
Hi,
Yesterday I sent the message below; I am new to this newsletter, please
let me know if I sent it correctly, thanks a lot!
I made a ming upgrade on my server. Whenever I create an action (new
SWFAction()) longer then 2000 characters I get :
child pid 2608 exit signal Segmentation fault (11).
I suspect a memory leak is causing this problem and it might be related
to the problem discussed here.
Thanks,
Yoav
> Absolutly,
>
> It's really in the php extension. I'm wondering what happen.. if the object reference is properly removed for the list and the C destructor is well called, where could be the problem inside the extension? This could be inside php code. I don't think that extensions that use the new zend api have this problem.
>
> Alan
>
> -----Original Message-----
> From: "Klaus Rechert" <kla...@rz...>
> Sent: Wednesday, October 29, 2008 6:00am
> To: "Alan Boudreault" <abo...@ma...>, "Ming Developers mailing list" <min...@li...>
> Subject: Re: [Ming-dev] Memory problem with the php extension ?
>
> Hi,
>
> sorry I was mostly offline the last few days. I poked a little bit in
> the code but haven't found a real solution yet.
>
> For sure is:
> 1. ming's shape() does not leak (checked via a C testcase)
> 2. memory usage scales with the number of instances
>
> I have the strong suspicion that the list holding the instances is not
> cleared.
>
> Cheers
> Klaus
>
>
>> Hi Klaus,
>>
>> I'm wondering if you have any new about the problem ? (Can you add me
>> in CC in the bugzilla plz)
>>
>> Thanks,
>> Alan
>>
>> Alan Boudreault wrote:
>>
>>> In fact, replacing the zend_list_insert by
>>> ZEND_REGISTER_RESOURCE........ has the same effect that removing the
>>> zend_list_addref().
>>>
>>> Alan
>>>
>>> Klaus Rechert wrote:
>>>
>>>> Hi Alan,
>>>>
>>>> the __construct function looks like this now:
>>>>
>>>> PHP_METHOD(swfshape, __construct)
>>>> {
>>>> SWFShape shape = newSWFShape();
>>>> int rsrc_id = ZEND_REGISTER_RESOURCE(return_value, shape,
>>>> le_swfshapep);
>>>> // int rsrc_id = zend_list_insert(shape, le_swfshapep);
>>>> object_init_ex(getThis(), shape_class_entry_ptr);
>>>> add_property_resource(getThis(), "shape", rsrc_id);
>>>> zend_list_addref(rsrc_id);
>>>> }
>>>>
>>>> Commenting the zend_list_addref() has no additional effect on memory
>>>> usage here.
>>>>
>>>> Thanks
>>>> Klaus
>>>>
>>>>
>>>>> Hi Klaus,
>>>>>
>>>>> I was writing you a comment on bugzilla.... but still waiting the
>>>>> account creation confirmation... here's what i wrote:
>>>>>
>>>>> If you comment the following line, in PHP_METHOD(swfshape,
>>>>> __construct) method:
>>>>> zend_list_addref(ret);
>>>>>
>>>>> The destructor is well called (verified with a printf in the
>>>>> destructor). BUT, the PHP OBJECT doesn't seem to be freed by php
>>>>> garbage collector. See what i get now:
>>>>>
>>>>> Beginning of script : 57368 bytes
>>>>>
>>>>> End of script : 769960 bytes
>>>>>
>>>>> So, there are still "memory leaks".
>>>>>
>>>>> Thanks,
>>>>> Alan
>>>>>
>>>>> Klaus Rechert wrote:
>>>>>
>>>>>
>>>>>> It is me again ;)
>>>>>>
>>>>>> Just dug a little bit in ZEND sources. Using
>>>>>> ZEND_REGISTER_RESOURCE() instead of zend_list_insert() made the
>>>>>> destructor function working. Running again your testcase results in:
>>>>>>
>>>>>> End of script : 1012316 bytes
>>>>>>
>>>>>> instead of
>>>>>>
>>>>>> End of script : 1524912 bytes for Ming 0.4.2.
>>>>>>
>>>>>> One little step... :)
>>>>>>
>>>>>> Cheers
>>>>>> Klaus
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> just checked your example. You are right PHP leaks. I'm not sure
>>>>>>> why... There are destructor functions defined and registered, but
>>>>>>> not called at all.
>>>>>>>
>>>>>>> I filed a bug
>>>>>>> http://bugs.libming.net/show_bug.cgi?id=74
>>>>>>>
>>>>>>> Thanks
>>>>>>> Klaus
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi guys, i'm wondering if you are aware of this problem using
>>>>>>>> your extension (or in the php garbage collector) ?
>>>>>>>>
>>>>>>>> See my script and results: http://pastebin.ca/1231918
>>>>>>>>
>>>>>>>> Do you know why the memory of the php object are not freed ?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alan
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> -------------------------------------------------------------------------
>>>>>>>
>>>>>>> This SF.Net email is sponsored by the Moblin Your Move
>>>>>>> Developer's challenge
>>>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>>>> great prizes
>>>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>>>> the world
>>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>>> _______________________________________________
>>>>>>> Ming-devr mailing list
>>>>>>> Min...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/ming-devr
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Ming-devr mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/ming-devr
>
>
|
|
From: <abo...@ma...> - 2008-10-29 13:03:34
|
Absolutly,
It's really in the php extension. I'm wondering what happen.. if the object reference is properly removed for the list and the C destructor is well called, where could be the problem inside the extension? This could be inside php code. I don't think that extensions that use the new zend api have this problem.
Alan
-----Original Message-----
From: "Klaus Rechert" <kla...@rz...>
Sent: Wednesday, October 29, 2008 6:00am
To: "Alan Boudreault" <abo...@ma...>, "Ming Developers mailing list" <min...@li...>
Subject: Re: [Ming-dev] Memory problem with the php extension ?
Hi,
sorry I was mostly offline the last few days. I poked a little bit in
the code but haven't found a real solution yet.
For sure is:
1. ming's shape() does not leak (checked via a C testcase)
2. memory usage scales with the number of instances
I have the strong suspicion that the list holding the instances is not
cleared.
Cheers
Klaus
> Hi Klaus,
>
> I'm wondering if you have any new about the problem ? (Can you add me
> in CC in the bugzilla plz)
>
> Thanks,
> Alan
>
> Alan Boudreault wrote:
>> In fact, replacing the zend_list_insert by
>> ZEND_REGISTER_RESOURCE........ has the same effect that removing the
>> zend_list_addref().
>>
>> Alan
>>
>> Klaus Rechert wrote:
>>> Hi Alan,
>>>
>>> the __construct function looks like this now:
>>>
>>> PHP_METHOD(swfshape, __construct)
>>> {
>>> SWFShape shape = newSWFShape();
>>> int rsrc_id = ZEND_REGISTER_RESOURCE(return_value, shape,
>>> le_swfshapep);
>>> // int rsrc_id = zend_list_insert(shape, le_swfshapep);
>>> object_init_ex(getThis(), shape_class_entry_ptr);
>>> add_property_resource(getThis(), "shape", rsrc_id);
>>> zend_list_addref(rsrc_id);
>>> }
>>>
>>> Commenting the zend_list_addref() has no additional effect on memory
>>> usage here.
>>>
>>> Thanks
>>> Klaus
>>>
>>>> Hi Klaus,
>>>>
>>>> I was writing you a comment on bugzilla.... but still waiting the
>>>> account creation confirmation... here's what i wrote:
>>>>
>>>> If you comment the following line, in PHP_METHOD(swfshape,
>>>> __construct) method:
>>>> zend_list_addref(ret);
>>>>
>>>> The destructor is well called (verified with a printf in the
>>>> destructor). BUT, the PHP OBJECT doesn't seem to be freed by php
>>>> garbage collector. See what i get now:
>>>>
>>>> Beginning of script : 57368 bytes
>>>>
>>>> End of script : 769960 bytes
>>>>
>>>> So, there are still "memory leaks".
>>>>
>>>> Thanks,
>>>> Alan
>>>>
>>>> Klaus Rechert wrote:
>>>>
>>>>> It is me again ;)
>>>>>
>>>>> Just dug a little bit in ZEND sources. Using
>>>>> ZEND_REGISTER_RESOURCE() instead of zend_list_insert() made the
>>>>> destructor function working. Running again your testcase results in:
>>>>>
>>>>> End of script : 1012316 bytes
>>>>>
>>>>> instead of
>>>>>
>>>>> End of script : 1524912 bytes for Ming 0.4.2.
>>>>>
>>>>> One little step... :)
>>>>>
>>>>> Cheers
>>>>> Klaus
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> just checked your example. You are right PHP leaks. I'm not sure
>>>>>> why... There are destructor functions defined and registered, but
>>>>>> not called at all.
>>>>>>
>>>>>> I filed a bug
>>>>>> http://bugs.libming.net/show_bug.cgi?id=74
>>>>>>
>>>>>> Thanks
>>>>>> Klaus
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi guys, i'm wondering if you are aware of this problem using
>>>>>>> your extension (or in the php garbage collector) ?
>>>>>>>
>>>>>>> See my script and results: http://pastebin.ca/1231918
>>>>>>>
>>>>>>> Do you know why the memory of the php object are not freed ?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alan
>>>>>>>
>>>>>>>
>>>>>> -------------------------------------------------------------------------
>>>>>>
>>>>>> This SF.Net email is sponsored by the Moblin Your Move
>>>>>> Developer's challenge
>>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>>> great prizes
>>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>>> the world
>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>> _______________________________________________
>>>>>> Ming-devr mailing list
>>>>>> Min...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/ming-devr
>>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
|
|
From: Yoav L. <yo...@co...> - 2008-10-29 12:45:32
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body dir="ltr" bgcolor="#ffffff" text="#000000">
<p style="margin-bottom: 0cm; margin-top: 0pt;"><small>Hi,</small></p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><span
style="font-size: 13px;"><br>
</span><span style="font-size: 13px;"></span></p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><span
style="font-size: 13px;">I made a ming upgrade on my server. Whenever
I create an action (new SWFAction()) longer then 2000 characters I get :<br>
</span><span style="font-size: 13px;"></span></p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><span
style="font-size: 13px;">child pid 2608 exit signal Segmentation fault
(11).</span></p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><span
style="font-size: 13px;">I suspect a memory leak is causing this
problem and it might be related to the problem discussed here.<br>
</span><span style="font-size: 13px;"></span></p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><span
style="font-size: 13px;"><br>
</span><span style="font-size: 13px;"></span></p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><span
style="font-size: 13px;">Thanks, <br>
</span><span style="font-size: 13px;"></span></p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><span
style="font-size: 13px;">Yoav</span><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><span
style="font-size: 13px;"></span></p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><span
style="font-size: 13px;"></span></p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><span
style="font-size: 13px;"></span></p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><span
style="font-size: 13px;"></span></p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<blockquote cite="mid:490...@rz..." type="cite">
<pre wrap="">Hi,
sorry I was mostly offline the last few days. I poked a little bit in
the code but haven't found a real solution yet.
For sure is:
1. ming's shape() does not leak (checked via a C testcase)
2. memory usage scales with the number of instances
I have the strong suspicion that the list holding the instances is not
cleared.
Cheers
Klaus
</pre>
<blockquote type="cite">
<pre wrap="">Hi Klaus,
I'm wondering if you have any new about the problem ? (Can you add me
in CC in the bugzilla plz)
Thanks,
Alan
Alan Boudreault wrote:
</pre>
<blockquote type="cite">
<pre wrap="">In fact, replacing the zend_list_insert by
ZEND_REGISTER_RESOURCE........ has the same effect that removing the
zend_list_addref().
Alan
Klaus Rechert wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Alan,
the __construct function looks like this now:
PHP_METHOD(swfshape, __construct)
{
SWFShape shape = newSWFShape();
int rsrc_id = ZEND_REGISTER_RESOURCE(return_value, shape,
le_swfshapep);
// int rsrc_id = zend_list_insert(shape, le_swfshapep);
object_init_ex(getThis(), shape_class_entry_ptr);
add_property_resource(getThis(), "shape", rsrc_id);
zend_list_addref(rsrc_id);
}
Commenting the zend_list_addref() has no additional effect on memory
usage here.
Thanks
Klaus
</pre>
<blockquote type="cite">
<pre wrap="">Hi Klaus,
I was writing you a comment on bugzilla.... but still waiting the
account creation confirmation... here's what i wrote:
If you comment the following line, in PHP_METHOD(swfshape,
__construct) method:
zend_list_addref(ret);
The destructor is well called (verified with a printf in the
destructor). BUT, the PHP OBJECT doesn't seem to be freed by php
garbage collector. See what i get now:
Beginning of script : 57368 bytes
End of script : 769960 bytes
So, there are still "memory leaks".
Thanks,
Alan
Klaus Rechert wrote:
</pre>
<blockquote type="cite">
<pre wrap="">It is me again ;)
Just dug a little bit in ZEND sources. Using
ZEND_REGISTER_RESOURCE() instead of zend_list_insert() made the
destructor function working. Running again your testcase results in:
End of script : 1012316 bytes
instead of
End of script : 1524912 bytes for Ming 0.4.2.
One little step... :)
Cheers
Klaus
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
just checked your example. You are right PHP leaks. I'm not sure
why... There are destructor functions defined and registered, but
not called at all.
I filed a bug
<a class="moz-txt-link-freetext" href="http://bugs.libming.net/show_bug.cgi?id=74">http://bugs.libming.net/show_bug.cgi?id=74</a>
Thanks
Klaus
</pre>
<blockquote type="cite">
<pre wrap="">Hi guys, i'm wondering if you are aware of this problem using
your extension (or in the php garbage collector) ?
See my script and results: <a class="moz-txt-link-freetext" href="http://pastebin.ca/1231918">http://pastebin.ca/1231918</a>
Do you know why the memory of the php object are not freed ?
Thanks,
Alan
</pre>
</blockquote>
<pre wrap="">-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move
Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win
great prizes
Grand prize is a trip for two to an Open Source event anywhere in
the world
<a class="moz-txt-link-freetext" href="http://moblin-contest.org/redirect.php?banner_id=100&url=/">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a>
_______________________________________________
Ming-devr mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Min...@li...">Min...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/ming-devr">https://lists.sourceforge.net/lists/listinfo/ming-devr</a>
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
<a class="moz-txt-link-freetext" href="http://moblin-contest.org/redirect.php?banner_id=100&url=/">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a>
_______________________________________________
Ming-devr mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Min...@li...">Min...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/ming-devr">https://lists.sourceforge.net/lists/listinfo/ming-devr</a>
</pre>
</blockquote>
<br>
</body>
</html>
|
|
From: Alan B. <abo...@ma...> - 2008-10-25 00:10:44
|
Hi Klaus,
I'm wondering if you have any new about the problem ? (Can you add me in
CC in the bugzilla plz)
Thanks,
Alan
Alan Boudreault wrote:
> In fact, replacing the zend_list_insert by
> ZEND_REGISTER_RESOURCE........ has the same effect that removing the
> zend_list_addref().
>
> Alan
>
> Klaus Rechert wrote:
>> Hi Alan,
>>
>> the __construct function looks like this now:
>>
>> PHP_METHOD(swfshape, __construct)
>> {
>> SWFShape shape = newSWFShape();
>> int rsrc_id = ZEND_REGISTER_RESOURCE(return_value, shape,
>> le_swfshapep);
>> // int rsrc_id = zend_list_insert(shape, le_swfshapep);
>> object_init_ex(getThis(), shape_class_entry_ptr);
>> add_property_resource(getThis(), "shape", rsrc_id);
>> zend_list_addref(rsrc_id);
>> }
>>
>> Commenting the zend_list_addref() has no additional effect on memory
>> usage here.
>>
>> Thanks
>> Klaus
>>
>>> Hi Klaus,
>>>
>>> I was writing you a comment on bugzilla.... but still waiting the
>>> account creation confirmation... here's what i wrote:
>>>
>>> If you comment the following line, in PHP_METHOD(swfshape,
>>> __construct) method:
>>> zend_list_addref(ret);
>>>
>>> The destructor is well called (verified with a printf in the
>>> destructor). BUT, the PHP OBJECT doesn't seem to be freed by php
>>> garbage collector. See what i get now:
>>>
>>> Beginning of script : 57368 bytes
>>>
>>> End of script : 769960 bytes
>>>
>>> So, there are still "memory leaks".
>>>
>>> Thanks,
>>> Alan
>>>
>>> Klaus Rechert wrote:
>>>
>>>> It is me again ;)
>>>>
>>>> Just dug a little bit in ZEND sources. Using
>>>> ZEND_REGISTER_RESOURCE() instead of zend_list_insert() made the
>>>> destructor function working. Running again your testcase results in:
>>>>
>>>> End of script : 1012316 bytes
>>>>
>>>> instead of
>>>>
>>>> End of script : 1524912 bytes for Ming 0.4.2.
>>>>
>>>> One little step... :)
>>>>
>>>> Cheers
>>>> Klaus
>>>>
>>>>
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> just checked your example. You are right PHP leaks. I'm not sure
>>>>> why... There are destructor functions defined and registered, but
>>>>> not called at all.
>>>>>
>>>>> I filed a bug
>>>>> http://bugs.libming.net/show_bug.cgi?id=74
>>>>>
>>>>> Thanks
>>>>> Klaus
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi guys, i'm wondering if you are aware of this problem using
>>>>>> your extension (or in the php garbage collector) ?
>>>>>>
>>>>>> See my script and results: http://pastebin.ca/1231918
>>>>>>
>>>>>> Do you know why the memory of the php object are not freed ?
>>>>>>
>>>>>> Thanks,
>>>>>> Alan
>>>>>>
>>>>>>
>>>>> -------------------------------------------------------------------------
>>>>>
>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>>> challenge
>>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>>> great prizes
>>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>>> the world
>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>> _______________________________________________
>>>>> Ming-devr mailing list
>>>>> Min...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/ming-devr
>>>>>
>>>
>>>
>>>
>>
>
>
--
Alan Boudreault
Mapgears
http://www.mapgears.com/
|
|
From: Alan B. <abo...@ma...> - 2008-10-21 13:40:54
|
In fact, replacing the zend_list_insert by
ZEND_REGISTER_RESOURCE........ has the same effect that removing the
zend_list_addref().
Alan
Klaus Rechert wrote:
> Hi Alan,
>
> the __construct function looks like this now:
>
> PHP_METHOD(swfshape, __construct)
> {
> SWFShape shape = newSWFShape();
> int rsrc_id = ZEND_REGISTER_RESOURCE(return_value, shape,
> le_swfshapep);
> // int rsrc_id = zend_list_insert(shape, le_swfshapep);
> object_init_ex(getThis(), shape_class_entry_ptr);
> add_property_resource(getThis(), "shape", rsrc_id);
> zend_list_addref(rsrc_id);
> }
>
> Commenting the zend_list_addref() has no additional effect on memory
> usage here.
>
> Thanks
> Klaus
>
>> Hi Klaus,
>>
>> I was writing you a comment on bugzilla.... but still waiting the
>> account creation confirmation... here's what i wrote:
>>
>> If you comment the following line, in PHP_METHOD(swfshape,
>> __construct) method:
>> zend_list_addref(ret);
>>
>> The destructor is well called (verified with a printf in the
>> destructor). BUT, the PHP OBJECT doesn't seem to be freed by php
>> garbage collector. See what i get now:
>>
>> Beginning of script : 57368 bytes
>>
>> End of script : 769960 bytes
>>
>> So, there are still "memory leaks".
>>
>> Thanks,
>> Alan
>>
>> Klaus Rechert wrote:
>>
>>> It is me again ;)
>>>
>>> Just dug a little bit in ZEND sources. Using
>>> ZEND_REGISTER_RESOURCE() instead of zend_list_insert() made the
>>> destructor function working. Running again your testcase results in:
>>>
>>> End of script : 1012316 bytes
>>>
>>> instead of
>>>
>>> End of script : 1524912 bytes for Ming 0.4.2.
>>>
>>> One little step... :)
>>>
>>> Cheers
>>> Klaus
>>>
>>>
>>>
>>>
>>>> Hi,
>>>>
>>>> just checked your example. You are right PHP leaks. I'm not sure
>>>> why... There are destructor functions defined and registered, but
>>>> not called at all.
>>>>
>>>> I filed a bug
>>>> http://bugs.libming.net/show_bug.cgi?id=74
>>>>
>>>> Thanks
>>>> Klaus
>>>>
>>>>
>>>>
>>>>
>>>>> Hi guys, i'm wondering if you are aware of this problem using your
>>>>> extension (or in the php garbage collector) ?
>>>>>
>>>>> See my script and results: http://pastebin.ca/1231918
>>>>>
>>>>> Do you know why the memory of the php object are not freed ?
>>>>>
>>>>> Thanks,
>>>>> Alan
>>>>>
>>>>>
>>>> -------------------------------------------------------------------------
>>>>
>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>> challenge
>>>> Build the coolest Linux based applications with Moblin SDK & win
>>>> great prizes
>>>> Grand prize is a trip for two to an Open Source event anywhere in
>>>> the world
>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>> _______________________________________________
>>>> Ming-devr mailing list
>>>> Min...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/ming-devr
>>>>
>>
>>
>>
>
--
Alan Boudreault
Mapgears
http://www.mapgears.com
|
|
From: Klaus R. <kla...@rz...> - 2008-10-21 13:36:55
|
Hi Alan,
the __construct function looks like this now:
PHP_METHOD(swfshape, __construct)
{
SWFShape shape = newSWFShape();
int rsrc_id = ZEND_REGISTER_RESOURCE(return_value, shape, le_swfshapep);
// int rsrc_id = zend_list_insert(shape, le_swfshapep);
object_init_ex(getThis(), shape_class_entry_ptr);
add_property_resource(getThis(), "shape", rsrc_id);
zend_list_addref(rsrc_id);
}
Commenting the zend_list_addref() has no additional effect on memory
usage here.
Thanks
Klaus
> Hi Klaus,
>
> I was writing you a comment on bugzilla.... but still waiting the
> account creation confirmation... here's what i wrote:
>
> If you comment the following line, in PHP_METHOD(swfshape, __construct)
> method:
> zend_list_addref(ret);
>
> The destructor is well called (verified with a printf in the
> destructor). BUT, the PHP OBJECT doesn't seem to be freed by php
> garbage collector. See what i get now:
>
> Beginning of script : 57368 bytes
>
> End of script : 769960 bytes
>
> So, there are still "memory leaks".
>
> Thanks,
> Alan
>
> Klaus Rechert wrote:
>
>> It is me again ;)
>>
>> Just dug a little bit in ZEND sources. Using ZEND_REGISTER_RESOURCE()
>> instead of zend_list_insert() made the destructor function working.
>> Running again your testcase results in:
>>
>> End of script : 1012316 bytes
>>
>> instead of
>>
>> End of script : 1524912 bytes for Ming 0.4.2.
>>
>> One little step... :)
>>
>> Cheers
>> Klaus
>>
>>
>>
>>
>>> Hi,
>>>
>>> just checked your example. You are right PHP leaks. I'm not sure
>>> why... There are destructor functions defined and registered, but not
>>> called at all.
>>>
>>> I filed a bug
>>> http://bugs.libming.net/show_bug.cgi?id=74
>>>
>>> Thanks
>>> Klaus
>>>
>>>
>>>
>>>
>>>> Hi guys, i'm wondering if you are aware of this problem using your
>>>> extension (or in the php garbage collector) ?
>>>>
>>>> See my script and results: http://pastebin.ca/1231918
>>>>
>>>> Do you know why the memory of the php object are not freed ?
>>>>
>>>> Thanks,
>>>> Alan
>>>>
>>>>
>>>>
>>> -------------------------------------------------------------------------
>>>
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Ming-devr mailing list
>>> Min...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ming-devr
>>>
>>>
>
>
>
|
|
From: Alan B. <abo...@ma...> - 2008-10-21 13:27:26
|
Hi Klaus, I was writing you a comment on bugzilla.... but still waiting the account creation confirmation... here's what i wrote: If you comment the following line, in PHP_METHOD(swfshape, __construct) method: zend_list_addref(ret); The destructor is well called (verified with a printf in the destructor). BUT, the PHP OBJECT doesn't seem to be freed by php garbage collector. See what i get now: Beginning of script : 57368 bytes End of script : 769960 bytes So, there are still "memory leaks". Thanks, Alan Klaus Rechert wrote: > It is me again ;) > > Just dug a little bit in ZEND sources. Using ZEND_REGISTER_RESOURCE() > instead of zend_list_insert() made the destructor function working. > Running again your testcase results in: > > End of script : 1012316 bytes > > instead of > > End of script : 1524912 bytes for Ming 0.4.2. > > One little step... :) > > Cheers > Klaus > > > >> Hi, >> >> just checked your example. You are right PHP leaks. I'm not sure >> why... There are destructor functions defined and registered, but not >> called at all. >> >> I filed a bug >> http://bugs.libming.net/show_bug.cgi?id=74 >> >> Thanks >> Klaus >> >> >> >>> Hi guys, i'm wondering if you are aware of this problem using your >>> extension (or in the php garbage collector) ? >>> >>> See my script and results: http://pastebin.ca/1231918 >>> >>> Do you know why the memory of the php object are not freed ? >>> >>> Thanks, >>> Alan >>> >>> >> >> >> ------------------------------------------------------------------------- >> >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win >> great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Ming-devr mailing list >> Min...@li... >> https://lists.sourceforge.net/lists/listinfo/ming-devr >> > -- Alan Boudreault Mapgears http://www.mapgears.com |
|
From: Klaus R. <kla...@rz...> - 2008-10-21 13:23:33
|
It is me again ;)
Just dug a little bit in ZEND sources. Using ZEND_REGISTER_RESOURCE()
instead of zend_list_insert() made the destructor function working.
Running again your testcase results in:
End of script : 1012316 bytes
instead of
End of script : 1524912 bytes for Ming 0.4.2.
One little step... :)
Cheers
Klaus
> Hi,
>
> just checked your example. You are right PHP leaks. I'm not sure why...
> There are destructor functions defined and registered, but not called at
> all.
>
> I filed a bug
> http://bugs.libming.net/show_bug.cgi?id=74
>
> Thanks
> Klaus
>
>
>
>> Hi guys, i'm wondering if you are aware of this problem using your
>> extension (or in the php garbage collector) ?
>>
>> See my script and results: http://pastebin.ca/1231918
>>
>> Do you know why the memory of the php object are not freed ?
>>
>> Thanks,
>> Alan
>>
>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Ming-devr mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/ming-devr
>
|
|
From: Klaus R. <kla...@rz...> - 2008-10-21 12:50:07
|
Hi, just checked your example. You are right PHP leaks. I'm not sure why... There are destructor functions defined and registered, but not called at all. I filed a bug http://bugs.libming.net/show_bug.cgi?id=74 Thanks Klaus > Hi guys, i'm wondering if you are aware of this problem using your > extension (or in the php garbage collector) ? > > See my script and results: http://pastebin.ca/1231918 > > Do you know why the memory of the php object are not freed ? > > Thanks, > Alan > > |
|
From: Alan B. <abo...@ma...> - 2008-10-20 16:22:01
|
Hi guys, i'm wondering if you are aware of this problem using your extension (or in the php garbage collector) ? See my script and results: http://pastebin.ca/1231918 Do you know why the memory of the php object are not freed ? Thanks, Alan -- Alan Boudreault Mapgears http://www.mapgears.com |
|
From: strk <st...@ke...> - 2008-10-08 10:46:44
|
Do we distribute ming_wrap.c by design ? It's a file generated by swig, I don't think we should distribute it. What's your opinion about it? --strk; () ASCII Ribbon Campaign /\ Keep it simple! |
|
From: Klaus R. <kl...@re...> - 2008-10-05 13:26:40
|
Hi, > The moveto() problem has been fixed since we last spoke, but I'm still > having some problems with gradients. If you'll note here > http://www.heynow.com/study/ming_gradient2/ only some of the > addEntry() calls are being honored when I put together a gradient. Can > you comment on what's going on? Thanks. > the SWF format has some limitations on gradients. MING's interface SWFGradient_addEntry() has a man page entry stating: SWF <= 7 allows up to 8 control points SWF >= 8 allows up to 15 control points In order to use up to 15 gradient entries you should also set the SWFShape version to 4: shape->useVersion(SWF_SHAPE4); Actually this part was missing in the interface documentation. I've just rendered your example and it looks OK to me. Cheers Klaus PS: Could you also contribute to Mings WIKI @ http://www.libming.net/ please? It is the only way to improve the documentation! |
|
From: Klaus R. <kla...@rz...> - 2008-10-02 09:03:27
|
Hi,
sound was one of the not so nice places of MING. Mostly because of a lot
codec related code distributed over several files. SWFSound and
SWFSoundStream did not share codec related code: e.g. uncompressed sound
(aka WAVE / PCM) was supported be SWFSound but not for SWFSoundStream,
SWFSoundStreams support FLV audio while SWFSound does not, etc...
Therefore I created a new SWFSoundInput object and one instance for each
supported sound codec. Such an object holds function pointers for common
tasks (like getSampleSize, skip, rewind, write, ...) to codec specific
implementations, such that SWFSound and SWFSoundStream can share now all
codec related tasks. In other words, if a codec is implemented properly,
it works on any sound object.
Also the newSWFSound() interface can be simplified. For WAV, FLV and MP3
input, pass 0 as flags and let MING determine the sound type and its
properties.
Attached is a patch for testing and reviewing. I'll commit it to CVS as
soon as we have separate branches for stable and dev code.
Cheers
Klaus
|
1 message has been excluded from this view by a project administrator.
