Two bugs processed

No.1

When the realtime sip peer is used and find_peer is called in the check_peer_ OK function of chan_sip.c, the peer name is not passed. If no peer is found in the memory through IP address and port,
You need to query the peer through ipaddr. Because there are many peers in the same ipaddr, the loaded data is large and crash is easy to appear. After the find_peer is attached with the name
When peer verification fails (asterisk servers cannot interwork), add a new name field in the find_peer_verify function to the peer's name value,
In this way, you can query the SIP by name.
Handle_request_invite (handle_request_subscribe)-> check_user_full-> check_peer_ OK-> find_peer (find_peer_verify)-> realtime_peer
Peer table.
#0 0x0033b809 in _ int_malloc () from/lib/libc. so.6
#1 0x0033c939 in calloc () from/lib/libc. so.6
#2 0x080a2db9 in _ ast_calloc (name = 0xd4af568 "company_id", value = 0x5da9110 "1", filename = 0x5a4333 "")
At/root/dreamstart/asterisk-1.6.0.26/include/asterisk/utils. h: 462
#3 ast_variable_new (name = 0xd4af568 "company_id", value = 0x5da9110 "1", filename = 0x5a4333 "") at config. C: 214
#4 0x005a0cb1 in _ i686.get _ pc_thunk.bx () from/usr/lib/asterisk/modules/res_config_mysql.so
#5 0x0d4af568 in ?? ()
#6 0x080a25d4 in ast_load_realtime_multientry (Family = 0x6a82cb3 "sippeers") at config. C: 2129
#7 0x06a56d66 in realtime_peer (newpeername = 0x0, sin = 0xd4a76d4, devstate_only = 0) at chan_sip.c: 3976
#8 bytes in check_peer_ OK (P = 0xd4a7400, of = 0x5de1a35 "88936", req = average, sipmethod = 5, sin = 0x5de314c, authpeer = 0x0, reliable = xmit_reliable,
Rpid_num = 0x5de1b62 "", calleridname = 0x5de1b30 "", uri2 = 0x5de19d0 "SIP: 8712_2_23_714@192.168.1.109") at chan_sip.c: 12761
#9 0x06a60030 in check_user_full (P = 0xd4a7400, req = 0x5de1f14, sipmethod = 5, uri = 0x5de0000f "SIP: 8712_2_23_714@192.168.1.109", reliable = xmit_reliable,
Sin = 0x5de314c, authpeer = 0x0) at chan_sip.c: 12999
#10 0x06a6a685 in check_user (P = 0xd4a7400, req = 0x5de1f14, DEBUG = 0, seqno = 20, sin = 0x5de314c, recount = 0x5de1ebc,
E = 0x5de0000f "SIP: 8712_2_23_714@192.168.1.109", nounlock = 0x5de1eb8) at chan_sip.c: 13026
#11 listen (P = 0xd4a7400, req = 0x5de1f14, DEBUG = 0, seqno = 20, sin = 0x5de314c, recount = 0x5de1ebc, E = 0x5de0000f "SIP: 8712_2_23_714@192.168.1.109 ",
Nounlock = 0x5de1eb8) at chan_sip.c: 18261
#12 0x06a7f385 in handle_incoming (P = 0xd4a7400, req = 0x5de1f14, sin = enabled, recount = 0x5de1ebc, nounlock = 0x5de1eb8) at chan_sip.c: 19890
#13 0x06a80ef7 in handle_request_do (req = 0x5de1f14, sin = 0x5de314c) at chan_sip.c: 20168
#14 0x06a81f70 in sipsock_read (ID = 0x9efccf8, FD = 16, events = 1, ignore = 0x0) at chan_sip.c: 20074
#15 0x080d45ef in ast_io_wait (IOC = 0x9efb4d0, Howlong = 1000) at Io. C: 288
#16 0x06a73a05 in do_monitor (Data = 0x0) at chan_sip.c: 20577
#17 0x0813725b in dummy_start (Data = 0x9efcfc0) at utils. C: 861
#18 0x00469a09 in start_thread () from/lib/libpthread. so.0
#19 0x003a743e in clone () from/lib/libc. so.6

No. 2

A webserver is embedded in the linphone-3.5.2 to communicate with the Web end over TCP. In this way, you can use Visual Studio to compile a client of the Soft Phone EXE to start the client. In this way, the TCP communication between the Web Client and the webserver completes the Linphone call, answer, and status retrieval process, you can also perform secondary development. This client runs on a non-Chinese xp pc. After 1 or 2 hours of stress call testing, a Windows Prompt appears: software error, whether to send an error (if it doesn't matter, the phone can work normally. If you click "send" or click "do not send", XP will kill the EXE program. However, this problem does not occur when you run the Chinese XP program. The Troubleshooting process is as follows:

1: it is suspected that the program is okay because of the XP environment. The error report function of disable on XP will not be sent under any circumstances, as a result, the EXE program disappears in the stress test.

Result: The error report cannot be sent by disable.

2: Because the EXE program generates a large number of logs, it is suspected that too many log files are generated, XP for security reasons, the user is prompted an error; the program shields the log for stress testing, an Error Report is also prompted.
Result: The log is not the cause of the Error Report.

3: Install Visual Studio on the client machine and compile the source code on the client machine for stress testing. The pressure test is normal for 10 hours without any prompts, and it is suspected that it is caused by an XP environment problem. The error report is: Visual Studio 2008 comes with 3.5. and 2.5 or 2.0 on the customer's machine.. net, so you are going.. Net updated to 3.5.. net. However, after Visual Studio is installed, just-in-time Debugger: An unhandled Win32 exception happened in xxxx.exe.
Studio is not very familiar with development, and it does not attract enough attention to this prompt. It does not locate the code error based on this debug information (another reason is that, regardless of this prompt, the EXE can still work normally, therefore, we think that it is only Windows's warning, not crash, and that the program is still running normally, debugging based on just-in-time cannot locate the error) (In fact, Windows will come with a try catch function. For an erroneous program, it can be captured so that the program does not immediately fail to work properly) (therefore, error reports and just-in-time prompts are all prompts that XP has caught program errors)

Result: I am not familiar with vs development and did not debug the just-in-time prompt.
4: Debug is performed based on just-in-time debugger and another error is made. Because EXE is multi-threaded, there are multiple threads during debugging, at this time, we chose not to debug the thread that crashed vs, but to check the underlying thread, and then thought that there was an error in the interrupted running of the underlying thread and the underlying code for repeated debugging had no effect.
Result: I am not familiar with vs development and did not debug the program (with a thread) that is really wrong.
5: the stress tests on multiple PCs on the client consume a lot of time and effort, and the results are not obvious.

6: I added a crash location to the program and run it again. I found that the vs prompt just-in-time Debugger: An unhandled Win32 exception happened in xxxx.exe ., in addition, VS is where the crash is displayed, so that debugging is performed in the place where the program is interrupted, that is, where the error occurs, and finally finds and fixes the program error.

When analyzing problems, we must start from the global perspective. We must consider various possible situations and try to solve them in different ways. We should never go to a dead end. At the same time, we also need to make a comparison and summary, so we cannot make useless attempts. Of course, the best case is the root cause of the problem that can be located at the beginning, which is the most time-saving and efficient, it is best to repeat the situations and conditions of the problem carefully, so you cannot guess it with the psychology of a blind cat encountering a dead mouse.

Two reasons for Linphone crash:

1: After operator executes the answer command, crash occurs. When linphone_core_accept_call is executed by Linphone, mediastream2.dll is abnormal because the caller has hung up the phone when the operator receives the call.
2: After the operator executes the hanging command, crash and linphone_core_terminate_call encounter an error during Linphone execution. mediastream2.dll is abnormal. Because the operator hangs up immediately after receiving the call, the call has not actually been established.
Linphone_core_stop_media_streams ()
{

...

Audio_stream_stop (LC-> audiostream );
...

}