tabskie / imsdroid

Automatically exported from code.google.com/p/imsdroid
0 stars 0 forks source link

Crash when using G.729 codec #546

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Build doubango using the attached patch to enable G.729 and enable debug.
2. Copy generated libs from android-projects/output/gpl/imsdroid/libs in 
android-ngn-stack 
3. Place a call between two smartphones running the generated version of 
Imsdroid using G.729 codec

What is the expected output? What do you see instead?
The call should stay up until one of the two parties hangs. The call, instead, 
is interrupted after a while (varing from seconds/minutes to hours) due to a 
crash of doubango on one of the parties.

What version of the product are you using? On what operating system?
Doubango r1233 / android-ngn-stack and imsdroid r579.
Reproduced on the following devices:
- Nexus 5/Android 5.0.1
- GT-I9505/Android 4.4.2
- SM-G900F/Android 4.4.2
- GT-I9100/Android 4.1.2

Please provide any additional information below.
Please find attached logcat and wireshark traces on a crash happened after few 
seconds on the GT-I9505 running Android 4.4.2.

Unfortunately, even enabling the debug (each version of tinyWRAP lib exceeds 
80MB), we don't get detailed info about the crash reason, just a line stated 
"Process org.doubango.imsdroid (pid 15298) (adj 0) has died".

Original issue reported on code.google.com by massimo....@gmail.com on 16 Feb 2015 at 9:09

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by boss...@yahoo.fr on 17 Feb 2015 at 8:52

GoogleCodeExporter commented 9 years ago
Tried with Doubango r1246 and imsdroid 580 on GT-I9100/Android 4.1.2 calling 
iPhone6 but cannot reproduce the crash.
Please try with my debug apk (https://ns313841.ovh.net/IMSDroid_g729.apk) and 
tell us if you have same crash.

Original comment by boss...@yahoo.fr on 18 Feb 2015 at 8:54

GoogleCodeExporter commented 9 years ago
Tried with the provided debug apk using two GT-I9100/Android 4.1.2 devices 
calling each other using G.729 codec (we don't have an iPhone 6 yet). On both 
devices we disabled the "Enable STUN for ICE", "Enable AEC", "VAD" and "Noise 
reduction" options.

After about 50 mintues we got the same crash on one of the phones(logs attached 
are not taken from the start of the call because the AudioHardwareYamaha 
generates logs continously and filled the Logcat buffer).

Please find also attached logs of the same crash occurred after about 10 
minutes under the same conditions on a GT-I9505/Android 4.4.2 calling a 
GT-I9100/Android 4.1.2.

Original comment by massimo....@gmail.com on 23 Feb 2015 at 9:35

Attachments:

GoogleCodeExporter commented 9 years ago
From the logs we see that before the app crash we get an error from the 
AudioRecord also some other native services die. It looks like a memory leak 
issue and testing long duration calls I noticed very few variations in the 
memory usage. The memory usage increase significantly each time we start a new 
call. The IMSDroid application won't free the leaked memory when you close it 
as the service will be running in the background. Use "shell top" to track 
memory usage and report it here.
Do you have the crash for the very first calls (after phone restart) or not?

Original comment by boss...@yahoo.fr on 25 Feb 2015 at 7:20

GoogleCodeExporter commented 9 years ago
Here the results of the following test:

- Got the Imsdroid apk provided installed on two GT-I9100 running Android 4.1.2
- Both phones have been rebooted
- After reboot, start Imsdroid and place a call between the two phones using 
G.729 codec.
- After few minutes Imsdroid crashed on one of the phones.

Please find attached the following log files captured using the following 
commands:

Logcat (w/o AudioHardwareYamaha logs): adb logcat -v time | grep --invert-match 
LVVEFS
Memory monitor: adb shell 'while true; do date && top -t -n 1 | grep imsdroid; 
sleep 1; done'

Original comment by massimo....@gmail.com on 2 Mar 2015 at 3:01

Attachments: