Jan,
Looking the logs hasn't revealed much telling info, but I'll go ahead and send you what I have anyways. I took the liberty of extracting this from my /var/logs/everything.log I was hoping there would be something more helpful regarding that memory allocation error. I do know, after looking at the source, that the "Can't allocate x-byte block" error is coming from my particular xmlrpc-c library. Interestingly enough I have a generic xmlrpc-c.tar.gz which does indicate very well what version it is on. Looking at the sourceforge page all of them have a particular schema which has left me wondering where I found this package. I am going to assume that it is ver 1.03.02, but I am going to go ahead and update it to see what happens, since there was a new release yesterday. I will let you know if that error persists after the update.
Logs:
Sep 6 09:23:00 myhost ./ser[5674]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5675]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5676]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5677]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5678]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5679]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5680]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5681]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5682]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5683]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5684]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5685]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5686]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5687]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5688]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5689]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5690]: INFO: signal 15 received Sep 6 09:23:22 myhost ser: read 936833521 from /dev/urandom Sep 6 09:23:22 myhost ser: seeding PRNG with 2062863074 Sep 6 09:23:22 myhost ser: test random number 923067521 Sep 6 09:23:22 myhost ser: WARNING: fix_socket_list: could not rev. resolve 63.77.68.19 Sep 6 09:23:22 myhost ./ser[5753]: Maxfwd module- initializing Sep 6 09:23:22 myhost ./ser[5753]: INFO: udp_init: SO_RCVBUF is initially 110592 Sep 6 09:23:22 myhost ./ser[5753]: INFO: udp_init: SO_RCVBUF is finally 221184 Sep 6 09:23:22 myhost ./ser[5753]: INFO: udp_init: SO_RCVBUF is initially 110592 Sep 6 09:23:22 myhost ./ser[5753]: INFO: udp_init: SO_RCVBUF is finally 221184 Sep 6 09:25:22 myhost ./ser[5770]: Binding 'testuser','sip:testUser@localhost' has expired Sep 6 09:25:48 myhost syslog-ng[1812]: STATS: dropped 0 Sep 6 09:27:23 myhost ./ser[5770]: Binding 'testuser','sip:testUser@localhost' has expired
Jan Janak wrote:
This is interesting. Your server sends "Can't allocate x-byte memory block" but this message does not come from SER, neither can I find it in my version of xmlrpc-c library.
What version of xmlrpc-c library do you have ? What is the OS/distribution ? Could you also send me the log from SER ?
thanks for helping me to debug this.
Jan.
Jan,
I installed the latest sourceforge release of the xmlrpc-c library [1.03.03] and I continue to get that error. The error can been found in src/xmlrpc_support.c
Are we using different xmlrpc C libraries?
Zach
zkeatts wrote:
Jan,
Looking the logs hasn't revealed much telling info, but I'll go ahead and send you what I have anyways. I took the liberty of extracting this from my /var/logs/everything.log I was hoping there would be something more helpful regarding that memory allocation error. I do know, after looking at the source, that the "Can't allocate x-byte block" error is coming from my particular xmlrpc-c library. Interestingly enough I have a generic xmlrpc-c.tar.gz which does indicate very well what version it is on. Looking at the sourceforge page all of them have a particular schema which has left me wondering where I found this package. I am going to assume that it is ver 1.03.02, but I am going to go ahead and update it to see what happens, since there was a new release yesterday. I will let you know if that error persists after the update.
Logs:
Sep 6 09:23:00 myhost ./ser[5674]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5675]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5676]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5677]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5678]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5679]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5680]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5681]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5682]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5683]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5684]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5685]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5686]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5687]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5688]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5689]: INFO: signal 15 received Sep 6 09:23:00 myhost ./ser[5690]: INFO: signal 15 received Sep 6 09:23:22 myhost ser: read 936833521 from /dev/urandom Sep 6 09:23:22 myhost ser: seeding PRNG with 2062863074 Sep 6 09:23:22 myhost ser: test random number 923067521 Sep 6 09:23:22 myhost ser: WARNING: fix_socket_list: could not rev. resolve 63.77.68.19 Sep 6 09:23:22 myhost ./ser[5753]: Maxfwd module- initializing Sep 6 09:23:22 myhost ./ser[5753]: INFO: udp_init: SO_RCVBUF is initially 110592 Sep 6 09:23:22 myhost ./ser[5753]: INFO: udp_init: SO_RCVBUF is finally 221184 Sep 6 09:23:22 myhost ./ser[5753]: INFO: udp_init: SO_RCVBUF is initially 110592 Sep 6 09:23:22 myhost ./ser[5753]: INFO: udp_init: SO_RCVBUF is finally 221184 Sep 6 09:25:22 myhost ./ser[5770]: Binding 'testuser','sip:testUser@localhost' has expired Sep 6 09:25:48 myhost syslog-ng[1812]: STATS: dropped 0 Sep 6 09:27:23 myhost ./ser[5770]: Binding 'testuser','sip:testUser@localhost' has expired
Jan Janak wrote:
This is interesting. Your server sends "Can't allocate x-byte memory block" but this message does not come from SER, neither can I find it in my version of xmlrpc-c library.
What version of xmlrpc-c library do you have ? What is the OS/distribution ? Could you also send me the log from SER ?
thanks for helping me to debug this.
Jan.
On 06-09-2005 10:04, zkeatts wrote:
Jan,
I installed the latest sourceforge release of the xmlrpc-c library [1.03.03] and I continue to get that error. The error can been found in src/xmlrpc_support.c
Are we using different xmlrpc C libraries?
Probably yes, because I am using an older version included in debian. I will test the functions with the latest version of xmlrpc-c, but I will do it after September 16th, because I am travelling now. I'll get back to you. Thanks for all the reports so far.
Jan.
Jan,
I have been able to narrow the error that is being caused to a specific execution flow in the program execution. By using print statments I basically printed out the function names to find out where it was coming from. The following is an excerpt of the output.
CONVERT_PARAMS[start] XMLRPC_BUILDVALUE BUILD VALUE INIT ARRAY ALLOCATING [0] MAKE_STRING XMLRPC_BUILDVALUE BUILD VALUE CASE S[] GET STRING[location] ALLOCATING [9] MAKE_STRING XMLRPC_BUILDVALUE BUILD VALUE CASE S[] GET STRING[testUser] ALLOCATING [9] CONVERT_PARAMS[end] RPC_ADD CASE[{}] XMLRPC_BUILDVALUE BUILD VALUE STRUCT INIT []ALLOCATING [0] PRINT_CONTACTS[start] <- This is located in ul_rpc.c RPC_STRUCT_ADD CASE[S] XMLRPC_BUILDVALUE BUILD VALUE CASE S[] GET STRING[xUÇ] <- This is where an error occurs ALLOCATING [3049756285] PRINT_CONTACTS[end] <- End of the function execution in ul_rpc.c START SEND BLOCK INIT SIZE [0] ALLOCATING [0] END SEND BLOCK XMLRPC_BUILDVALUE BUILD VALUE STRUCT INIT []ALLOCATING [0] getStructMem KEY CASE S[] GET STRING[faultCode] ALLOCATING [10] getStructMem VALUE getStructMem KEY CASE S[] GET STRING[faultString] ALLOCATING [12] getStructMem VALUE CASE S[] GET STRING[Can't allocate 3049756285-byte memory block: size [3049756285] allocated [16]] ALLOCATING [83] INIT SIZE [10] ALLOCATING [10] INIT SIZE [12] ALLOCATING [12] INIT SIZE [83] ALLOCATING [83]
Jan Janak wrote:
On 06-09-2005 10:04, zkeatts wrote:
Jan,
I installed the latest sourceforge release of the xmlrpc-c library [1.03.03] and I continue to get that error. The error can been found in src/xmlrpc_support.c
Are we using different xmlrpc C libraries?
Probably yes, because I am using an older version included in debian. I will test the functions with the latest version of xmlrpc-c, but I will do it after September 16th, because I am travelling now. I'll get back to you. Thanks for all the reports so far.
Jan.
Jan,
I have been able to determine that the %u-byte error that the xml-rpc library is giving me comes from the following.
In modules/xmlrpc.c
there is a method called rpc_struct_add that has several execution cases. The error I have been getting apparently is connected to the following snippet of code.
case 'S': str_val = va_arg(ap, str*);
fprintf(stderr, "STR_S[%s] STR_LEN[%u]", str_val->s, str_val->len);
val = xmlrpc_build_value(&rpc_ctx.env, "s#", str_val->s, str_val->len); if (rpc_ctx.env.fault_occurred) goto error; break;
Notice how I added that fprint statement. I was curious as to what exactly was being passed to the xmlrpc functions and why it would give such a large u-byte block. Printing the contents of str_val usually yields the following
STR_S[xe¹] STR_LEN[3048842876]
It seems to me that the "structure" being passed is empty? All I know is that this particular function is called from /modules/usr_loc/ul_rpc.c => print_contacts
Do you maybe have an idea of what is going on with that structure?
Thanks,
Zach Keatts
Jan Janak wrote:
On 06-09-2005 10:04, zkeatts wrote:
Jan,
I installed the latest sourceforge release of the xmlrpc-c library [1.03.03] and I continue to get that error. The error can been found in src/xmlrpc_support.c
Are we using different xmlrpc C libraries?
Probably yes, because I am using an older version included in debian. I will test the functions with the latest version of xmlrpc-c, but I will do it after September 16th, because I am travelling now. I'll get back to you. Thanks for all the reports so far.
Jan.
-
Jan Janak -
zkeatts