Re: Problem in MP3 encoding

On Sun, 14 Sep 2014 17:10:44 +0000
[email protected] wrote:


> Dear sir,
>               Hope you will be fine. Sir, I am using your open soucre
> libray for mp3 encoding. It is really wonderful. I use this
> technology in one of my Android application. After every few days, I
> received crash report of my application due in lame library. I
> searched a lot on net but not succeeded. The crash trace by Google in
> my application is following:

The right place to discuss this is the lame-dev mailinglist (in CC).
Unfortunately the backtrace doesn't contain enough information to say
something. Looks like the lame lib is not compiled with debug info (or
the debug info got stripped out when building your app), so we don't
know exactly why it is failing.

As we don't provide an android version, and as I see "dalvik-heap"
here, I suspect the interface from the dalvik virtual machine to the
lame library is at fault here. Looks like the memory is not managed
correctly. We can't rule out a memory problem in LAME, but given the
maturity I consider it not very likely. I rather think you should
review the java<->lame interface.

The backtrace (for lame-dev@)... hopefully not mangled by my mailer:
---snip---
Build fingerprint: 'Micromax/A106/A106:4.4.2/KOT49H/1399562071:user/release-keys'
pid: 7014, tid: 30178, name: Thread-6440 >>> com.ultimate.myapp<<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
r0 5bb6dc48 r1 421d4390 r2 421d4390 r3 fff88e3b
r4 00000000 r5 000006e0 r6 00000004 r7 421d4390
r8 5fc0bad8 r9 5f790f80 sl 5f76fa80 fp 5fc0baec
ip 00000001 sp 5fc0ba84 lr 5f7b07ad pc 5f7a2dbe cpsr 000b0030

backtrace:
#00 pc 0000fdbe /mnt/asec/com.ultimate.myapp-1/lib/libmp3lame.so (lame_encode_buffer+13)
#01 pc 0022e0dc /dev/ashmem/dalvik-heap (deleted)

code around pc:
5f7a2d9c 0001182d 00011bba 00011bcc 0001187b 
5f7a2dac 0001153a 1c1db5f0 33fc1c03 1c1769dc 
5f7a2dbc 68224b23 9007b089 429a1c0e 1e28d139 
5f7a2dcc 1c20d03b f7ff1c29 2800f951 4b1dd133 
5f7a2ddc 58e39002 4b1c9304 58e39a04 93059206 
5f7a2dec e0189303 5ef02300 ec48f00e c2019a06 
5f7a2dfc 4a169206 2b0158a3 2300dd05 f00e5ef8 
5f7a2e0c 9a03ec3e 9b026010 36029a03 32043301 
5f7a2e1c 37029302 9b029203 dbe342ab 98079b0e 
5f7a2e2c 93009904 9a059b0f 1c2b9301 f962f7ff 
5f7a2e3c 2003e003 2002e000 b0094240 46c0bdf0 
5f7a2e4c fff88e3b 00015ad4 00015ad8 00007ca0 
5f7a2e5c 1c1db5f0 33fc1c03 1c1669dc 68224b1c 
5f7a2e6c 9007b089 429a1c0f 1e28d12b 1c20d02d 
5f7a2e7c f7ff1c29 2800f8fb 4b16d125 58e19703 
5f7a2e8c 91064b15 1c1358e2 e00e4694 ca809a03 

code around lr:
5f7b078c 990f1c28 47982200 90044b14 447b1c39 
5f7b079c 9b046818 94019a03 9b0e9300 fb02f7f2 
5f7b07ac 26c2682b 599c00b6 90071c3a 1c289905 
5f7b07bc 47a02300 1c28682b 599c9906 23009a03 
5f7b07cc 682a47a0 009b23c0 1c2858d4 9a04990f 
5f7b07dc 47a02300 b0099807 46c0bdf0 0000ba7e 
5f7b07ec 1c16b5f7 23ab6802 1c31009b 1c0558d3 
5f7b07fc 682a4798 009b23b8 1c041c31 1c2858d3 
5f7b080c 47982200 1c074b09 447b1c39 68181c22 
5f7b081c ff2cf7f3 23c0682a 58d4009b 1c319001 
5f7b082c 1c3a1c28 47a02300 bdfe9801 0000ba02 
5f7b083c 4c04b510 6820447c ffecf7f3 60232300 
5f7b084c 46c0bd10 0000b9d8 4671b402 00490849 
5f7b085c 00495c09 bc02448e 46c04770 4671b403 
5f7b086c 00400849 5a090049 448e0049 4770bc03 
5f7b087c e2512001 012fff1e 3a000023 e1500001 
---snip---


Bye,
Alexander.

-- 
http://www.Leidinger.net [email protected]: PGP 0xC773696B3BAC17DC
http://www.FreeBSD.org    [email protected]  : PGP 0xC773696B3BAC17DC

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk