+1. Thanks, -Manjula.
On Tue, 2008-07-08 at 16:54 +0530, Damitha Kumarage wrote: > Hi devs, > > I would like to nominate Diluka Moratuwage to be an Axis2/C commiter. > > Diluka has contributed some important patches to Savan/C. He implemented > XPath filtering support and fault handling for Savan/C. He has also > contributed patches to Axis2/C and has been active in mailing list. > > I am confident that Diluka will continue to make his valuable > contributions to Axis2/C and Savan/C projects. > > Please refer to the attached jira report for more information about his > contributions. > > Here is my vote. +1 > > Thanks, > Damitha > HTML document attachment (diluka-jira.html) > [AXIS2C-688] Savan fault handling > and filter dialect support Created: > 05/Sep/07 Updated: 19/Sep/07 > Status: > > > Closed > > > Project: > > > Axis2-C > > > Component/s: > > > None > > > Affects Version/s: > > > None > > > Fix Version/s: > > > None > > > > > Type: > > > Improvement > > > Priority: > > > Major > > > Reporter: > > > Diluka > Moratuwage > > > Assignee: > > > Unassigned > > > Resolution: > > > Fixed > > > Votes: > > > 0 > > > Remaining > Estimate: > > > Not Specified > > > Time Spent: > > > Not Specified > > > Original > Estimate: > > > Not Specified > > > > > File Attachments: > > > Text File > savan-filtering-faults.patch > > > > > Description > > > > > > Savan fault handling and filter dialect support implemented. > > > > > Comments > > > > > > Comment by Damitha Kumarage [ 10/Sep/07 06:21 AM ] > > > Patch Applied. Thanks Diluka for the important patch. I tested with > the subscriber sample and it looks OK > > > Comment by Damitha Kumarage [ 19/Sep/07 02:51 AM ] > > > No issues so far. So close it > > > > ______________________________________________________________________ > > > > [AXIS2C-552] Code formatting for > axis2c/axiom Created: 19/Mar/07 > Updated: 19/Mar/07 > Status: > > > Resolved > > > Project: > > > Axis2-C > > > Component/s: > > > None > > > Affects Version/s: > > > None > > > Fix Version/s: > > > 1.0.0 > > > > > Type: > > > Improvement > > > Priority: > > > Minor > > > Reporter: > > > Diluka > Moratuwage > > > Assignee: > > > Dinesh Premalal > > > Resolution: > > > Fixed > > > Votes: > > > 0 > > > Remaining > Estimate: > > > Not Specified > > > Time Spent: > > > Not Specified > > > Original > Estimate: > > > Not Specified > > > > > File Attachments: > > > File patch.axiom > > > > > Description > > > > > > Code formatted in axiom/soap and axiom/attachments > > > > > Comments > > > > > > Comment by Diluka Moratuwage [ 19/Mar/07 03:02 AM ] > > > Macros removed, and code formatted in axiom/soap and > axiom/attachmens. > > > Comment by Dinesh Premalal [ 19/Mar/07 12:25 PM ] > > > patch applied , thanks Diluka, Keep them coming > > > > ______________________________________________________________________ > > > > [AXIS2C-652] XPath filtering > support for savan Created: > 26/Jul/07 Updated: 04/Sep/07 > Status: > > > Resolved > > > Project: > > > Axis2-C > > > Component/s: > > > None > > > Affects Version/s: > > > None > > > Fix Version/s: > > > None > > > > > Type: > > > Improvement > > > Priority: > > > Major > > > Reporter: > > > Diluka > Moratuwage > > > Assignee: > > > Unassigned > > > Resolution: > > > Fixed > > > Votes: > > > 0 > > > Remaining > Estimate: > > > Not Specified > > > Time Spent: > > > Not Specified > > > Original > Estimate: > > > Not Specified > > > Environment: > > > Ubuntu 7.04 > > > > > File Attachments: > > > Text File filtering.patch File > template.xsl > > > > > Description > > > > > > XPath, filtering for elements, without a namespace prefix is > supported. Since, we still don't have XPath filtering in axis2c, I > have explicitly used, libxslt library. Error handling is yet to be > done. > > > > > Comments > > > > > > Comment by Diluka Moratuwage [ 26/Jul/07 09:14 PM ] > > > The template.xsl is a file used by the sre/util/savan_util.c file. > Please keep it in src/util directory. > > > Comment by Damitha Kumarage [ 27/Jul/07 12:18 AM ] > > > Diluka, I have applied the patch and it does not break existing > functionlity. Could you please send some testing code so that I could > test the filtering functionlity. You can update the existing savan > sample to test the filtering > > > Comment by Samisa Abeysinghe [ 04/Sep/07 07:50 PM ] > > > Pathces has been applies to Savan svn head. Many thanks for the > patches. > > > > ______________________________________________________________________ > > > > [AXIS2C-556] Code formatting for > Axis2/c Created: 19/Mar/07 > Updated: 19/Mar/07 > Status: > > > Resolved > > > Project: > > > Axis2-C > > > Component/s: > > > None > > > Affects Version/s: > > > None > > > Fix Version/s: > > > 1.0.0 > > > > > Type: > > > Improvement > > > Priority: > > > Major > > > Reporter: > > > Diluka > Moratuwage > > > Assignee: > > > Dinesh Premalal > > > Resolution: > > > Fixed > > > Votes: > > > 0 > > > Remaining > Estimate: > > > Not Specified > > > Time Spent: > > > Not Specified > > > Original > Estimate: > > > Not Specified > > > > > File Attachments: > > > File patch.receivers > > > > > Description > > > > > > Macros removed and code formatted in modules/core/receivers. > > > > > Comments > > > > > > Comment by Diluka Moratuwage [ 19/Mar/07 10:24 PM ] > > > Code formatted and macros removed in modules/core/receivers. > > > Comment by Diluka Moratuwage [ 19/Mar/07 10:29 PM ] > > > Macros removed and code formatted in modules/core/receivers > > > Comment by Dinesh Premalal [ 19/Mar/07 10:52 PM ] > > > patch applied! , Thanks Diluka > > > > ______________________________________________________________________ > > > > [AXIS2C-555] Code formatting for > axis2c/phaseresolver Created: > 19/Mar/07 Updated: 19/Mar/07 > Status: > > > Resolved > > > Project: > > > Axis2-C > > > Component/s: > > > None > > > Affects Version/s: > > > None > > > Fix Version/s: > > > 1.0.0 > > > > > Type: > > > Improvement > > > Priority: > > > Minor > > > Reporter: > > > Diluka > Moratuwage > > > Assignee: > > > Dinesh Premalal > > > Resolution: > > > Fixed > > > Votes: > > > 0 > > > Remaining > Estimate: > > > Not Specified > > > Time Spent: > > > Not Specified > > > Original > Estimate: > > > Not Specified > > > > > File Attachments: > > > File patch.phaseresolver > > > > > Description > > > > > > Code formatted in /modules/core/phaseresolver, and removed macros. > > > > > Comments > > > > > > Comment by Diluka Moratuwage [ 19/Mar/07 05:23 AM ] > > > Removed macros and code formatted in, modules/core/phaseresolver > > > Comment by Dinesh Premalal [ 19/Mar/07 12:27 PM ] > > > patch applied, Many thanks Diluka, > > > > ______________________________________________________________________ > > > > [AXIS2C-547] Code formatting for > axis2c/utils Created: 11/Mar/07 > Updated: 17/Mar/07 > Status: > > > Resolved > > > Project: > > > Axis2-C > > > Component/s: > > > util > > > Affects Version/s: > > > None > > > Fix Version/s: > > > 1.0.0 > > > > > Type: > > > Improvement > > > Priority: > > > Minor > > > Reporter: > > > Diluka > Moratuwage > > > Assignee: > > > Dinesh Premalal > > > Resolution: > > > Fixed > > > Votes: > > > 0 > > > Remaining > Estimate: > > > Not Specified > > > Time Spent: > > > Not Specified > > > Original > Estimate: > > > Not Specified > > > > > File Attachments: > > > File patch.util > > > > > Description > > > > > > Removed macros, and code formatted for utils package > > > > > Comments > > > > > > Comment by Diluka Moratuwage [ 15/Mar/07 12:11 AM ] > > > Macros removed. Code was formatted to achieve more readability. And > unneccessary codes were removed. > > > Comment by Samisa Abeysinghe [ 16/Mar/07 05:35 AM ] > > > I tried applying this patch on Windows but failed. Can someone please > try this on Linux please.... > > > Comment by Dinesh Premalal [ 17/Mar/07 01:26 AM ] > > > patch applied ! Thanks Diluka > > > > ______________________________________________________________________ > > > > [AXIS2C-899] zlib library should > not be included when > AXIS2_ARCHIVE_ENABLED is false. > Created: 15/Jan/08 Updated: > 09/Feb/08 > Status: > > > Resolved > > > Project: > > > Axis2-C > > > Component/s: > > > build system > > > Affects Version/s: > > > 1.3.0 > > > Fix Version/s: > > > 1.3.0 > > > > > Type: > > > Bug > > > Priority: > > > Minor > > > Reporter: > > > Diluka > Moratuwage > > > Assignee: > > > Senaka Fernando > > > Resolution: > > > Fixed > > > Votes: > > > 0 > > > Remaining > Estimate: > > > Not Specified > > > Time Spent: > > > Not Specified > > > Original > Estimate: > > > Not Specified > > > Environment: > > > Ubuntu 7.04 > > > > > File Attachments: > > > Text File zlib.patch > > > > > Description > > > > > > When AXIS2_ARCHIVE_ENABLED is false, zlib library should not be > included in util. > > > > > Comments > > > > > > Comment by Diluka Moratuwage [ 15/Jan/08 08:32 PM ] > > > When AXIS2_ARCHIVE_ENABLED is false, zlib is not needed to be included > in util. > > > Comment by Senaka Fernando [ 09/Feb/08 01:49 PM ] > > > Hi all, zlib.h is not a unix specific include. Can't we just remove > this from platforms/unix/axutil_unix.h? Regards, Senaka > > > Comment by Senaka Fernando [ 09/Feb/08 11:20 PM ] > > > Hi all, We simply can remove this from the axutil_unix.h header. I > removed this include and successfully ran with archive based > deployment. Thanks Diluka for pointing this out. Regards, Senaka > > > > ______________________________________________________________________ > > > > [AXIS2C-1154] multiple Invalid read > of size 4 for client In-Only > message Created: 21/May/08 > Updated: 30/Jun/08 > Status: > > > Resolved > > > Project: > > > Axis2-C > > > Component/s: > > > None > > > Affects Version/s: > > > 1.4.0 > > > Fix Version/s: > > > None > > > > > Type: > > > Bug > > > Priority: > > > Major > > > Reporter: > > > Frederic Heem > > > Assignee: > > > Supun > Kamburugamuva > > > Resolution: > > > Fixed > > > Votes: > > > 0 > > > Remaining > Estimate: > > > Not Specified > > > Time Spent: > > > Not Specified > > > Original > Estimate: > > > Not Specified > > > Environment: > > > linux fc5 > > > > > File Attachments: > > > File notify_client.c Text File > send_robust.patch > > > > > Description > > > > > > When sending an "In-Only" message, valgrind complains about multiple > invalid read : ==13318== Invalid read of size 4 ==13318== at > 0x4049F37: axis2_msg_ctx_get_transport_in_desc (msg_ctx.c:1075) > ==13318== by 0x405577E: axis2_svc_client_set_http_info > (svc_client.c:1703) ==13318== by 0x40563D8: > axis2_svc_client_send_robust_with_op_qname (svc_client.c:571) > ==13318== by 0x804B477: axis2_stub_op_zigbee_PermitJoining > (axis2_stub_zigbee.c:1248) ==13318== by 0x804A362: PermitJoining > (zigbee_client.c:221) ==13318== by 0x804A523: main > (zigbee_client.c:132) ==13318== Address 0x423a298 is 48 bytes inside a > block of size 264 free'd ==13318== at 0x40053CC: free > (vg_replace_malloc.c:323) ==13318== by 0x411289C: > axutil_allocator_free_impl (allocator.c:91) ==13318== by 0x404CBE9: > axis2_msg_ctx_free (msg_ctx.c:540) ==13318== by 0x4053E3C: > axis2_op_client_add_msg_ctx (op_client.c:226) ==13318== by 0x40544E4: > axis2_op_client_execute (op_client.c:522) ==13318== by 0x40563C9: > axis2_svc_client_send_robust_with_op_qname (svc_client.c:570) > ==13318== by 0x804B477: axis2_stub_op_zigbee_PermitJoining > (axis2_stub_zigbee.c:1248) ==13318== by 0x804A362: PermitJoining > (zigbee_client.c:221) ==13318== by 0x804A523: main > (zigbee_client.c:132) ==13318== ==13318== Invalid read of size 4 > ==13318== at 0x4048447: axis2_msg_ctx_get_status_code (msg_ctx.c:2662) > ==13318== by 0x4055877: axis2_svc_client_set_http_info > (svc_client.c:1756) ==13318== by 0x40563D8: > axis2_svc_client_send_robust_with_op_qname (svc_client.c:571) > ==13318== by 0x804B477: axis2_stub_op_zigbee_PermitJoining > (axis2_stub_zigbee.c:1248) ==13318== by 0x804A362: PermitJoining > (zigbee_client.c:221) ==13318== by 0x804A523: main > (zigbee_client.c:132) ==13318== Address 0x423a2f0 is 136 bytes inside > a block of size 264 free'd ==13318== at 0x40053CC: free > (vg_replace_malloc.c:323) ==13318== by 0x411289C: > axutil_allocator_free_impl (allocator.c:91) ==13318== by 0x404CBE9: > axis2_msg_ctx_free (msg_ctx.c:540) ==13318== by 0x4053E3C: > axis2_op_client_add_msg_ctx (op_client.c:226) ==13318== by 0x40544E4: > axis2_op_client_execute (op_client.c:522) ==13318== by 0x40563C9: > axis2_svc_client_send_robust_with_op_qname (svc_client.c:570) > ==13318== by 0x804B477: axis2_stub_op_zigbee_PermitJoining > (axis2_stub_zigbee.c:1248) ==13318== by 0x804A362: PermitJoining > (zigbee_client.c:221) ==13318== by 0x804A523: main > (zigbee_client.c:132) ==13318== ==13318== Invalid read of size 4 > ==13318== at 0x4048347: axis2_msg_ctx_get_auth_failed (msg_ctx.c:2683) > ==13318== by 0x40563E4: axis2_svc_client_send_robust_with_op_qname > (svc_client.c:572) ==13318== by 0x804B477: > axis2_stub_op_zigbee_PermitJoining (axis2_stub_zigbee.c:1248) > ==13318== by 0x804A362: PermitJoining (zigbee_client.c:221) ==13318== > by 0x804A523: main (zigbee_client.c:132) ==13318== Address 0x423a360 > is 248 bytes inside a block of size 264 free'd ==13318== at 0x40053CC: > free (vg_replace_malloc.c:323) ==13318== by 0x411289C: > axutil_allocator_free_impl (allocator.c:91) ==13318== by 0x404CBE9: > axis2_msg_ctx_free (msg_ctx.c:540) ==13318== by 0x4053E3C: > axis2_op_client_add_msg_ctx (op_client.c:226) ==13318== by 0x40544E4: > axis2_op_client_execute (op_client.c:522) ==13318== by 0x40563C9: > axis2_svc_client_send_robust_with_op_qname (svc_client.c:570) > ==13318== by 0x804B477: axis2_stub_op_zigbee_PermitJoining > (axis2_stub_zigbee.c:1248) ==13318== by 0x804A362: PermitJoining > (zigbee_client.c:221) ==13318== by 0x804A523: main > (zigbee_client.c:132) ==13318== ==13318== Invalid read of size 4 > ==13318== at 0x4048147: axis2_msg_ctx_get_required_auth_is_http > (msg_ctx.c:2725) ==13318== by 0x40563F6: > axis2_svc_client_send_robust_with_op_qname (svc_client.c:573) > ==13318== by 0x804B477: axis2_stub_op_zigbee_PermitJoining > (axis2_stub_zigbee.c:1248) ==13318== by 0x804A362: PermitJoining > (zigbee_client.c:221) ==13318== by 0x804A523: main > (zigbee_client.c:132) ==13318== Address 0x423a364 is 252 bytes inside > a block of size 264 free'd ==13318== at 0x40053CC: free > (vg_replace_malloc.c:323) ==13318== by 0x411289C: > axutil_allocator_free_impl (allocator.c:91) ==13318== by 0x404CBE9: > axis2_msg_ctx_free (msg_ctx.c:540) ==13318== by 0x4053E3C: > axis2_op_client_add_msg_ctx (op_client.c:226) ==13318== by 0x40544E4: > axis2_op_client_execute (op_client.c:522) ==13318== by 0x40563C9: > axis2_svc_client_send_robust_with_op_qname (svc_client.c:570) > ==13318== by 0x804B477: axis2_stub_op_zigbee_PermitJoining > (axis2_stub_zigbee.c:1248) ==13318== by 0x804A362: PermitJoining > (zigbee_client.c:221) ==13318== by 0x804A523: main > (zigbee_client.c:132) ==13318== ==13318== Invalid read of size 4 > ==13318== at 0x4048017: axis2_msg_ctx_get_auth_type (msg_ctx.c:2761) > ==13318== by 0x804B477: axis2_stub_op_zigbee_PermitJoining > (axis2_stub_zigbee.c:1248) ==13318== by 0x804A362: PermitJoining > (zigbee_client.c:221) ==13318== by 0x804A523: main > (zigbee_client.c:132) ==13318== Address 0x423a368 is 256 bytes inside > a block of size 264 free'd ==13318== at 0x40053CC: free > (vg_replace_malloc.c:323) ==13318== by 0x411289C: > axutil_allocator_free_impl (allocator.c:91) ==13318== by 0x404CBE9: > axis2_msg_ctx_free (msg_ctx.c:540) ==13318== by 0x4053E3C: > axis2_op_client_add_msg_ctx (op_client.c:226) ==13318== by 0x40544E4: > axis2_op_client_execute (op_client.c:522) ==13318== by 0x40563C9: > axis2_svc_client_send_robust_with_op_qname (svc_client.c:570) > ==13318== by 0x804B477: axis2_stub_op_zigbee_PermitJoining > (axis2_stub_zigbee.c:1248) ==13318== by 0x804A362: PermitJoining > (zigbee_client.c:221) ==13318== by 0x804A523: main > (zigbee_client.c:132) > > > > > Comments > > > > > > Comment by Diluka Moratuwage [ 11/Jun/08 02:48 AM ] > > > Hi, Can you please attach the source file of your program (or another > similar sample of how you use it). I checked with a sample on my own, > and didn't find such issue with that function. Thanks, Diluka. > > > Comment by Frederic Heem [ 11/Jun/08 02:57 AM ] > > > Have you changed the definition of AXIS2_MALLOC and friends ? Please > modify axutil_allocator.h: #if 0 #define AXIS2_MALLOC(allocator, size) > \ ((allocator)->malloc_fn(allocator, size)) #define > AXIS2_REALLOC(allocator, ptr, size) \ > ((allocator)->realloc(allocator, ptr, size)) #define > AXIS2_FREE(allocator, ptr) \ ((allocator)->free_fn(allocator, > ptr)) #else #include <stdlib.h> #define AXIS2_MALLOC(allocator, size) > \ malloc(size) #define AXIS2_REALLOC(allocator, ptr, size) \ > realloc(ptr, size) #define AXIS2_FREE(allocator, ptr) \ > free(ptr) #endif > > > Comment by Diluka Moratuwage [ 11/Jun/08 05:01 AM ] > > > Hi, The above modification doesn't do anything wrong. I tested that, > so I'm sure you must have done some mistake in your source code. I > suggest you to have a look at echo sample, and get some idea. Or else > if you can send the source code, we can have a look. Thanks, Diluka. > > > Comment by Frederic Heem [ 11/Jun/08 05:43 AM ] > > > The modification is a workaround for a valgrind issue, without it, > valgrind is not able to detect the problem. Moreover, the echo example > is not an In-Only message, therefore, it will not exhibit the problem. > Is there any example with a "In-Only" message ? Here is the part of > the wsdl used for this message: <xsd:element > name="PermitJoiningParam"> <xsd:complexType > <xsd:sequence> > <xsd:element name="permitDuration" type="xsd:unsignedByte"/> > </xsd:sequence> </xsd:complexType> </xsd:element> <wsdl:message > name="PermitJoiningMsg"> <wsdl:part name="permitJoiningParam" > element="tns:PermitJoiningParam" /> </wsdl:message> <wsdl:operation > name="PermitJoining"> <wsdl:input message="tns:PermitJoiningMsg" /> > </wsdl:operation> <wsdl:operation name="PermitJoining"> > <soap:operation soapAction="PermitJoining" style="document"/> > <wsdl:input> <soap:body use="literal" /> </wsdl:input> > </wsdl:operation> > > > Comment by Diluka Moratuwage [ 24/Jun/08 05:17 AM ] > > > Hi Frederic, You can check notify sample code, in order to have some > idea of in-only operations. By the way, I checked it for the invalid > read using valgrind. It's a known bug that comes from dl library. > Actually it's not a bug in the Axis2/C code. Thanks, Diluka. > > > Comment by Frederic Heem [ 24/Jun/08 05:27 AM ] > > > A bug from the dl library ? Can you please point me to a reference of > this issue ? I just want to be 100% it is not a bug from axis2c. Best > Regards, > > > Comment by Diluka Moratuwage [ 24/Jun/08 06:00 AM ] > > > Hi Frederic, I wrote a simple program, that loads a dll without using > any Axis code (of course I used dl library), then tested with > valgrind, the same problem, comes. So this will confirm you that, it's > not originating from the Axis library. Thanks, Diluka. > > > Comment by Frederic Heem [ 24/Jun/08 06:23 AM ] > > > Dear Diluka. Sorry but I really don't understand. You wrote a simple > program which doesn't use any axis2 code and you get the same error, > that is an invalid read in the axis code ? I'm sure there is a > misunderstanding, can you please be more precise ? Best Regards, > Frederic > > > Comment by Diluka Moratuwage [ 24/Jun/08 08:11 AM ] > > > Hi Frederic, Well, I just noted that, I tried to reproduce the exact > error as you got, but I'm sorry I was unable, but I found that there > is an invalid read due to library loading (That is because of the use > of dl library). If you write a simple program, that would load any > library, and you run it using valgrind, I found that, it has an > invalid read from function dlopen(). I only could regenerate that and > I didn't get any invalid read from any other function. It seems that > you get invalid read due to some other problem. I think we have to see > a simple sample to get the problem soloved. By the way, if you need a > sample on how to use axis2_svc_client_send_robust_with_op_qname > function, I suggest you to have a look into the notify sample, it > shows how exactly you can use that. Thanks, Diluka. > > > Comment by Frederic Heem [ 25/Jun/08 09:15 AM ] > > > Actually, the dl library is not used because the problem comes from > the client side. Therefore, the invalid read cannot come from this > library but comes from either axis2 code or axis2 generated code. > Moreover, the notify example doesn't use > axis2_svc_client_send_robust_with_op_qname but uses > axis2_svc_client_send_robust. It should be useful that one write a > simple In-Only example using the WSDL2C compiler. > > > Comment by Frederic Heem [ 25/Jun/08 10:01 AM ] > > > This modified notify_client.c uses the same mechanism than the WSDL2C > generated code. The invalid read can be reproduced with that file. > > > Comment by Supun Kamburugamuva [ 26/Jun/08 02:11 AM ] > > > Hi Frederic, I assume the trace you have produced is using modified > MALLOC and FREE functions. In that case how axutil_allocator_free_impl > this function get called? Supun.. > > > Comment by Frederic Heem [ 26/Jun/08 02:32 AM ] > > > Indeed, MALLOC and FREE needs to be modified and mapped directly to > malloc() and free(). In that case, axutil_allocator_free_impl is not > called. > > > Comment by Supun Kamburugamuva [ 26/Jun/08 02:52 AM ] > > > But I can see that function is getting called in your trace. I checked > your sample with Purify under Windows XP. But I didn't get the invalid > read. Need to check on Linux. > > > Comment by Frederic Heem [ 26/Jun/08 03:13 AM ] > > > In the given trace, axutil_allocator_free_impl is called .. .and I > don't know why. Anyay, here is the valgrind trace with > notify_client.c: ==15367== Invalid read of size 4 ==15367== at > 0x404AB67: axis2_msg_ctx_get_transport_in_desc (msg_ctx.c:1075) > ==15367== by 0x405624E: axis2_svc_client_set_http_info > (svc_client.c:1703) ==15367== by 0x4056E8E: > axis2_svc_client_send_robust_with_op_qname (svc_client.c:571) > ==15367== by 0x8049081: main (notify_client.c:134) ==15367== Address > 0x4228f70 is 48 bytes inside a block of size 264 free'd ==15367== at > 0x40053FC: free (vg_replace_malloc.c:323) ==15367== by 0x404D7D5: > axis2_msg_ctx_free (msg_ctx.c:540) ==15367== by 0x405490C: > axis2_op_client_add_msg_ctx (op_client.c:226) ==15367== by 0x4054FAA: > axis2_op_client_execute (op_client.c:522) ==15367== by 0x4056E7F: > axis2_svc_client_send_robust_with_op_qname (svc_client.c:570) > ==15367== by 0x8049081: main (notify_client.c:134) ==15367== ==15367== > Invalid read of size 4 ==15367== at 0x4049077: > axis2_msg_ctx_get_status_code (msg_ctx.c:2662) ==15367== by 0x4056347: > axis2_svc_client_set_http_info (svc_client.c:1756) ==15367== by > 0x4056E8E: axis2_svc_client_send_robust_with_op_qname > (svc_client.c:571) ==15367== by 0x8049081: main (notify_client.c:134) > ==15367== Address 0x4228fc8 is 136 bytes inside a block of size 264 > free'd ==15367== at 0x40053FC: free (vg_replace_malloc.c:323) > ==15367== by 0x404D7D5: axis2_msg_ctx_free (msg_ctx.c:540) ==15367== > by 0x405490C: axis2_op_client_add_msg_ctx (op_client.c:226) ==15367== > by 0x4054FAA: axis2_op_client_execute (op_client.c:522) ==15367== by > 0x4056E7F: axis2_svc_client_send_robust_with_op_qname > (svc_client.c:570) ==15367== by 0x8049081: main (notify_client.c:134) > ==15367== ==15367== Invalid read of size 4 ==15367== at 0x4048F77: > axis2_msg_ctx_get_auth_failed (msg_ctx.c:2683) ==15367== by 0x4056E9A: > axis2_svc_client_send_robust_with_op_qname (svc_client.c:572) > ==15367== by 0x8049081: main (notify_client.c:134) ==15367== Address > 0x4229038 is 248 bytes inside a block of size 264 free'd ==15367== at > 0x40053FC: free (vg_replace_malloc.c:323) ==15367== by 0x404D7D5: > axis2_msg_ctx_free (msg_ctx.c:540) ==15367== by 0x405490C: > axis2_op_client_add_msg_ctx (op_client.c:226) ==15367== by 0x4054FAA: > axis2_op_client_execute (op_client.c:522) ==15367== by 0x4056E7F: > axis2_svc_client_send_robust_with_op_qname (svc_client.c:570) > ==15367== by 0x8049081: main (notify_client.c:134) ==15367== ==15367== > Invalid read of size 4 ==15367== at 0x4048D77: > axis2_msg_ctx_get_required_auth_is_http (msg_ctx.c:2725) ==15367== by > 0x4056EAC: axis2_svc_client_send_robust_with_op_qname > (svc_client.c:573) ==15367== by 0x8049081: main (notify_client.c:134) > ==15367== Address 0x422903c is 252 bytes inside a block of size 264 > free'd ==15367== at 0x40053FC: free (vg_replace_malloc.c:323) > ==15367== by 0x404D7D5: axis2_msg_ctx_free (msg_ctx.c:540) ==15367== > by 0x405490C: axis2_op_client_add_msg_ctx (op_client.c:226) ==15367== > by 0x4054FAA: axis2_op_client_execute (op_client.c:522) ==15367== by > 0x4056E7F: axis2_svc_client_send_robust_with_op_qname > (svc_client.c:570) ==15367== by 0x8049081: main (notify_client.c:134) > ==15367== ==15367== Invalid read of size 4 ==15367== at 0x4048B87: > axis2_msg_ctx_get_auth_type (msg_ctx.c:2761) ==15367== by 0x8049081: > main (notify_client.c:134) ==15367== Address 0x4229040 is 256 bytes > inside a block of size 264 free'd ==15367== at 0x40053FC: free > (vg_replace_malloc.c:323) ==15367== by 0x404D7D5: axis2_msg_ctx_free > (msg_ctx.c:540) ==15367== by 0x405490C: axis2_op_client_add_msg_ctx > (op_client.c:226) ==15367== by 0x4054FAA: axis2_op_client_execute > (op_client.c:522) ==15367== by 0x4056E7F: > axis2_svc_client_send_robust_with_op_qname (svc_client.c:570) > ==15367== by 0x8049081: main (notify_client.c:134) > > > Comment by Supun Kamburugamuva [ 26/Jun/08 09:01 PM ] > > > Hi Fredric, I think you have a small mistake in your client code and > that alters normal behavior of Axis2/C and causes the invalid reads, > The mistake is you are making the message exchange pattern > AXIS2_MEP_URI_IN_ONLY. This is for the server side. In client side you > should specify AXIS2_MEP_URI_OUT_ONLY for one way messages. Because in > client side what you are doing is sending but not expecting a result. > Anyway we should not have those invalid read if a user done a wrong > configuration as well. I will correct the code ASAP. Supun.. > > > Comment by Supun Kamburugamuva [ 26/Jun/08 11:04 PM ] > > > Here is a fix for handling incorrect message patterns configurations > by users for send robust case. If we don't handle this it leads to > invalid memory reads. I would like some one with more experience in > this area to have a look before I apply the patch. > > > Comment by Damitha Kumarage [ 27/Jun/08 01:33 AM ] > > > Supun, Your fix makes sense to me. What Frederic doing is from his > client application he retrieves the anonymous svc client and create a > new operation for it and call send_robust with that op name. But he > set the wrong MEP for it. What your patch do is check whether the mep > is correctly set for the operation. If not you return failure. I > approve that patch. Please commit it. > > > Comment by Supun Kamburugamuva [ 27/Jun/08 01:36 AM ] > > > Applied the patch. Thanks Damitha for reviewing it. > > > Comment by Frederic Heem [ 27/Jun/08 02:44 AM ] > > > Actually, the code that incorrectly sets to MEP is generated by > WSDL2C, it has been cut and paste to notify_client.c . Therefore the > issue is not completely closed. WSDL2C has to be fixed to set the > correct MEP for client In-Only MEP. Regards, > > > Comment by Supun Kamburugamuva [ 27/Jun/08 02:54 AM ] > > > Please create a new Jira as this is not related to the Axis2/C client > API. Supun.. On Fri, Jun 27, 2008 at 2:45 PM, Frederic Heem (JIRA) > <[EMAIL PROTECTED]> > > > Comment by Frederic Heem [ 30/Jun/08 07:54 AM ] > > > The patch doesn't work when used with the generated code. In this case > the mep the code is trying to compare is empty. The easiest way is to > create a sample application which uses WSDL2C and add various type of > messages, In-Only, In-Out, with or without parameter .... Best > Regards, > > > Comment by Frederic Heem [ 30/Jun/08 07:57 AM ] > > > Actually, there is a cosmetic issue with the patch, tabs are present > but the rest of the file uses spaces. > > > > ______________________________________________________________________ > > > > [AXIS2C-1211] Improving the > AXIS2_SVC_SKELETON_INIT_WITH_CONF > Created: 30/Jun/08 Updated: > 01/Jul/08 > Status: > > > Resolved > > > Project: > > > Axis2-C > > > Component/s: > > > None > > > Affects Version/s: > > > None > > > Fix Version/s: > > > None > > > > > Type: > > > Bug > > > Priority: > > > Major > > > Reporter: > > > Diluka > Moratuwage > > > Assignee: > > > Unassigned > > > Resolution: > > > Fixed > > > Votes: > > > 0 > > > Remaining > Estimate: > > > Not Specified > > > Time Spent: > > > Not Specified > > > Original > Estimate: > > > Not Specified > > > Environment: > > > Ubuntu 7.04 > > > > > File Attachments: > > > Text File conf_ctx.patch > > > > > Description > > > > > > I have some problem with AXIS2_SVC_SKELETON_INIT_WITH_CONF macro. > Apparently it allows the service to use the configuration, within the > service, when it's starting up. But, by the time this function is > called (when loading services), we have already created the conf_ctx. > And as I have seen the very usage of this comes when a service have to > be started up. But in order to use it, we have to create conf_ctx > within the service most probably. So I think it will be > appropriate to send the conf_ctx instead of conf into a service. So if > the service has any need of the conf, still it can get the conf from > the conf_ctx. > > > > > Comments > > > > > > Comment by Damitha Kumarage [ 30/Jun/08 08:32 AM ] > > > Diluka, Can you show me a specific situation where conf_ctx needed in > service initialization. In Savan/C I can see that in publishing client > sample and subscription manager service a conf_ctx is created out of > conf passed to init function. But even there it is not neccessary to > create such a cont_ctx because it is not used for any useful things. > It is created just because publishing cliet needs it. But when you > look at publising client code it does not use it either. It jusr > retrieve conf from it. It is the only use publishing client has from > conf_ctx. So my suggestion is to pass just the conf to the service > init as it is now. But in Savan/C we need to change publishing client > code not to accept a conf_ctx but a conf. > > > Comment by Diluka Moratuwage [ 01/Jul/08 02:33 AM ] > > > Yes that is true, even though we create conf_ctx within subs_mgr and > publisher services, it's not actually needed. I have attached a patch > which removes all unnecessary usages of conf_ctx, and modified the > publishing client, so that it no longer has a conf_ctx within that. > > > Comment by Diluka Moratuwage [ 01/Jul/08 02:36 AM ] > > > This patch removes all unnecessary use of conf_ctx within savan module > services. > > > Comment by Supun Kamburugamuva [ 01/Jul/08 02:52 AM ] > > > Hi Diluka, I think the patch you provided is for savan/c not Axis2/C > -). Supun.. > > > Comment by Damitha Kumarage [ 01/Jul/08 04:04 AM ] > > > Diluka, I applied the patch and it seems ok. Thanks for the patch. > > > > ______________________________________________________________________ > > > > [AXIS2C-1219] Savan remote subs_mgr > gives an internal server error > Created: 01/Jul/08 Updated: > 06/Jul/08 > Status: > > > Resolved > > > Project: > > > Axis2-C > > > Component/s: > > > None > > > Affects Version/s: > > > None > > > Fix Version/s: > > > None > > > > > Type: > > > Bug > > > Priority: > > > Major > > > Reporter: > > > Diluka > Moratuwage > > > Assignee: > > > Damitha Kumarage > > > Resolution: > > > Fixed > > > Votes: > > > 0 > > > Remaining > Estimate: > > > Not Specified > > > Time Spent: > > > Not Specified > > > Original > Estimate: > > > Not Specified > > > Environment: > > > Ubuntu 7.04 > > > > > File Attachments: > > > Text File subs_mgr.patch > > > > > Description > > > > > > When there is no subscriber is registered with savan_sub_mgr, the > get_subscriber_list gives an internal server error. And we have to set > MEP of subs_mgr service's add_subscriber operation to in-only, in > order to avoid internal server error, when it's used. > > > > > Comments > > > > > > Comment by Diluka Moratuwage [ 01/Jul/08 06:53 AM ] > > > This patch avoids internal server error msgs that comes when obtaining > subscriber list, and it also modifies the mep of the add_subscriber > operation of subs_mgr to avoid internal server errors. > > > Comment by Damitha Kumarage [ 06/Jul/08 10:45 AM ] > > > Patch applied. Thanks Diluka > > > > ______________________________________________________________________ > > > > Generated at Sun Jul 06 11:07:40 PDT 2008 using JIRA Enterprise > Edition, Version: 3.12.2-#300. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
