We are running into some strange issues on Froyo when building for
Sapphire. Notably, issues with prelinked libraries not loading into
the right address space. libaudio was the first, and a quick fix there
was to just disable prelinking for it. Now it gets stranger with
libcamera/liboemcamera..
E/QualcommCameraHardware( 64): FATAL ERROR: could not dlopen
liboemcamera.so: Cannot load library: reserve_mem_region[831]:
OOPS: 64 prelinked library 'liboemcamera.so' mapped at
0x40b0c000, not at 0xa9400000
When the linker mmaps the library, it's ending up in the wrong place.
The isprelinked tool says that it's OK though:
> We are running into some strange issues on Froyo when building for
> Sapphire. Notably, issues with prelinked libraries not loading into
> the right address space. libaudio was the first, and a quick fix there
> was to just disable prelinking for it. Now it gets stranger with
> libcamera/liboemcamera..
> E/QualcommCameraHardware( 64): FATAL ERROR: could not dlopen
> liboemcamera.so: Cannot load library: reserve_mem_region[831]:
> OOPS: 64 prelinked library 'liboemcamera.so' mapped at
> 0x40b0c000, not at 0xa9400000
> When the linker mmaps the library, it's ending up in the wrong place.
> The isprelinked tool says that it's OK though:
> I can confirm this issue, which also came up on my Tattoo. Hope the
> devs from google can fix it.
> On Jun 30, 12:36 pm, cyanogen <steve.kon...@gmail.com> wrote:
> > We are running into some strange issues on Froyo when building for
> > Sapphire. Notably, issues with prelinked libraries not loading into
> > the right address space. libaudio was the first, and a quick fix there
> > was to just disable prelinking for it. Now it gets stranger with
> > libcamera/liboemcamera..
> > E/QualcommCameraHardware( 64): FATAL ERROR: could not dlopen
> > liboemcamera.so: Cannot load library: reserve_mem_region[831]:
> > OOPS: 64 prelinked library 'liboemcamera.so' mapped at
> > 0x40b0c000, not at 0xa9400000
> > When the linker mmaps the library, it's ending up in the wrong place.
> > The isprelinked tool says that it's OK though:
> Here is the logcat while libspeech.so dlopen-ed after I set the
> DLINKER_DEBUG to 1:
> E/linker ( 523): bionic/linker/linker.c:672| WARNING: `/system/lib/
> libspeech.so` is not a prelinked library
> E/linker ( 523): 59 mapping library 'libspeech.so' at 80900000
> (index 00000009) through buddy allocator.
> E/linker ( 523): bionic/linker/linker.c:1280| ERROR: 59 cannot
> locate '_ZN7android11AudioRecordC1EijiiijPFviPvS1_ES1_i'...
> E/linker ( 523):
> E/linker ( 523): bionic/linker/linker.c:1995| ERROR: failed to link
> libspeech.so
> E/linker ( 523):
> I/dalvikvm( 523): Unable to dlopen(/system/lib/libspeech.so): Cannot
> load library: link_image[1995]: failed to link libspeech.so
> There seems to be some illogic codes in linker.c file.
> Regards,
> On Jun 30, 4:09 pm, aBiNg <cn.fyo...@gmail.com> wrote:
> > Hi, cyanogen
> > I can confirm this issue, which also came up on my Tattoo. Hope the
> > devs from google can fix it.
> > On Jun 30, 12:36 pm, cyanogen <steve.kon...@gmail.com> wrote:
> > > We are running into some strange issues on Froyo when building for
> > > Sapphire. Notably, issues with prelinked libraries not loading into
> > > the right address space. libaudio was the first, and a quick fix there
> > > was to just disable prelinking for it. Now it gets stranger with
> > > libcamera/liboemcamera..
> > > E/QualcommCameraHardware( 64): FATAL ERROR: could not dlopen
> > > liboemcamera.so: Cannot load library: reserve_mem_region[831]:
> > > OOPS: 64 prelinked library 'liboemcamera.so' mapped at
> > > 0x40b0c000, not at 0xa9400000
> > > When the linker mmaps the library, it's ending up in the wrong place.
> > > The isprelinked tool says that it's OK though:
I would assume that some of the prelinked libraries loaded are larger than what the prelink map expects, resulting in overlaps/conflicts. You will probably need to modify the prelink map.
A prelinked library cannot be relocated to a different address (on purpose, the goal is to get rid of all internal relocations, to speed up loading and reduce code size), which is why the linker is complaining with a fatal error.
isprelinked returns true for your library because it detects that it has already been "pre-relocated" for 0xa94000000, but that doesn't mean it can always be loaded into a process' address space.
On Tue, Jun 29, 2010 at 9:36 PM, cyanogen <steve.kon...@gmail.com> wrote: > We are running into some strange issues on Froyo when building for > Sapphire. Notably, issues with prelinked libraries not loading into > the right address space. libaudio was the first, and a quick fix there > was to just disable prelinking for it. Now it gets stranger with > libcamera/liboemcamera..
> E/QualcommCameraHardware( 64): FATAL ERROR: could not dlopen > liboemcamera.so: Cannot load library: reserve_mem_region[831]: > OOPS: 64 prelinked library 'liboemcamera.so' mapped at > 0x40b0c000, not at 0xa9400000
> When the linker mmaps the library, it's ending up in the wrong place. > The isprelinked tool says that it's OK though:
> For some reason this is only happening on Sapphire/Dream. Passion > builds work just fine.
> Ideas?
> -- > You received this message because you are subscribed to the Google Groups > "android-platform" group. > To post to this group, send email to android-platform@googlegroups.com. > To unsubscribe from this group, send email to > android-platform+unsubscribe@googlegroups.com<android-platform%2Bunsubscrib e@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/android-platform?hl=en.
Thanks for the response. I checked this, but the alloted space in the
prelink map is 2MB and the library in question is only 300k. The same
problem happens with a different library (libaudio) and there is
plenty of space for it as well. Everything is fine on Passion builds,
it's only happening when building for Dream/Sapphire.
> I would assume that some of the prelinked libraries loaded are larger than
> what the prelink
> map expects, resulting in overlaps/conflicts. You will probably need to
> modify the prelink map.
> A prelinked library cannot be relocated to a different address (on purpose,
> the goal
> is to get rid of all internal relocations, to speed up loading and reduce
> code size),
> which is why the linker is complaining with a fatal error.
> isprelinked returns true for your library because it detects that it has
> already been
> "pre-relocated" for 0xa94000000, but that doesn't mean it can always be
> loaded
> into a process' address space.
> Hope this helps
> On Tue, Jun 29, 2010 at 9:36 PM, cyanogen <steve.kon...@gmail.com> wrote:
> > We are running into some strange issues on Froyo when building for
> > Sapphire. Notably, issues with prelinked libraries not loading into
> > the right address space. libaudio was the first, and a quick fix there
> > was to just disable prelinking for it. Now it gets stranger with
> > libcamera/liboemcamera..
> > E/QualcommCameraHardware( 64): FATAL ERROR: could not dlopen
> > liboemcamera.so: Cannot load library: reserve_mem_region[831]:
> > OOPS: 64 prelinked library 'liboemcamera.so' mapped at
> > 0x40b0c000, not at 0xa9400000
> > When the linker mmaps the library, it's ending up in the wrong place.
> > The isprelinked tool says that it's OK though:
> > For some reason this is only happening on Sapphire/Dream. Passion
> > builds work just fine.
> > Ideas?
> > --
> > You received this message because you are subscribed to the Google Groups
> > "android-platform" group.
> > To post to this group, send email to android-platform@googlegroups.com.
> > To unsubscribe from this group, send email to
> > android-platform+unsubscribe@googlegroups.com<android-platform%2Bunsubscrib e@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/android-platform?hl=en.
On Jun 30, 11:11 am, cyanogen <steve.kon...@gmail.com> wrote:
> Thanks for the response. I checked this, but the alloted space in the
> prelink map is 2MB and the library in question is only 300k. The same
> problem happens with a different library (libaudio) and there is
> plenty of space for it as well. Everything is fine on Passion builds,
> it's only happening when building for Dream/Sapphire.
Did you check the library *below* the library that's failing? The
address-specific mmap() call would fail if another library had been
loaded below it and exceeded its bounds.
0x40b0c000 is in the right area for a "next available" space
allocation. Looking at linker.c, we're not specifying MAP_FIXED, so
this behavior is expected.
Checked that, and I also added some extra debug code to print si->size
in reserve_mem_region, and I can't see anywhere it's overrunning the
prelink space. Something is fishy.
On Jun 30, 4:51 pm, fadden <fad...@android.com> wrote:
> On Jun 30, 11:11 am, cyanogen <steve.kon...@gmail.com> wrote:
> > Thanks for the response. I checked this, but the alloted space in the
> > prelink map is 2MB and the library in question is only 300k. The same
> > problem happens with a different library (libaudio) and there is
> > plenty of space for it as well. Everything is fine on Passion builds,
> > it's only happening when building for Dream/Sapphire.
> Did you check the library *below* the library that's failing? The
> address-specific mmap() call would fail if another library had been
> loaded below it and exceeded its bounds.
> 0x40b0c000 is in the right area for a "next available" space
> allocation. Looking at linker.c, we're not specifying MAP_FIXED, so
> this behavior is expected.
On Thu, Jul 1, 2010 at 1:33 AM, cyanogen <steve.kon...@gmail.com> wrote: > Checked that, and I also added some extra debug code to print si->size > in reserve_mem_region, and I can't see anywhere it's overrunning the > prelink space. Something is fishy.
> On Jun 30, 4:51 pm, fadden <fad...@android.com> wrote: >> On Jun 30, 11:11 am, cyanogen <steve.kon...@gmail.com> wrote:
>> > Thanks for the response. I checked this, but the alloted space in the >> > prelink map is 2MB and the library in question is only 300k. The same >> > problem happens with a different library (libaudio) and there is >> > plenty of space for it as well. Everything is fine on Passion builds, >> > it's only happening when building for Dream/Sapphire.
>> Did you check the library *below* the library that's failing? The >> address-specific mmap() call would fail if another library had been >> loaded below it and exceeded its bounds.
>> 0x40b0c000 is in the right area for a "next available" space >> allocation. Looking at linker.c, we're not specifying MAP_FIXED, so >> this behavior is expected.
> -- > You received this message because you are subscribed to the Google Groups "android-platform" group. > To post to this group, send email to android-platform@googlegroups.com. > To unsubscribe from this group, send email to android-platform+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
> Is there a chance something, like a system update, might have
> disturbed your toolchain?
> Do other releases build for the Dream OK?
> On Thu, Jul 1, 2010 at 1:33 AM, cyanogen <steve.kon...@gmail.com> wrote:
> > Checked that, and I also added some extra debug code to print si->size
> > in reserve_mem_region, and I can't see anywhere it's overrunning the
> > prelink space. Something is fishy.
> > On Jun 30, 4:51 pm, fadden <fad...@android.com> wrote:
> >> On Jun 30, 11:11 am, cyanogen <steve.kon...@gmail.com> wrote:
> >> > Thanks for the response. I checked this, but the alloted space in the
> >> > prelink map is 2MB and the library in question is only 300k. The same
> >> > problem happens with a different library (libaudio) and there is
> >> > plenty of space for it as well. Everything is fine on Passion builds,
> >> > it's only happening when building for Dream/Sapphire.
> >> Did you check the library *below* the library that's failing? The
> >> address-specific mmap() call would fail if another library had been
> >> loaded below it and exceeded its bounds.
> >> 0x40b0c000 is in the right area for a "next available" space
> >> allocation. Looking at linker.c, we're not specifying MAP_FIXED, so
> >> this behavior is expected.
> > --
> > You received this message because you are subscribed to the Google Groups "android-platform" group.
> > To post to this group, send email to android-platform@googlegroups.com.
> > To unsubscribe from this group, send email to android-platform+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/android-platform?hl=en.
You are right, my libspeech.so issue has been fixed.
As for the liboemcamera.so issue, we have the exactly same problem.
logcat is here:
E/QualcommCameraHardware( 60): FATAL ERROR: could not dlopen
liboemcamera.so: Cannot load library: reserve_mem_region[810]:
OOPS: 60 prelinked library 'liboemcamera.so' mapped at
0x40d0c000, not at 0xa9400000
The corresponding address of 0xa9400000 is referred to
libvorbisidec.so library. Are they overlapped, as fadden said?
And I read reports by other people that dynamic libraries would be
inflated while being called. Is this true?
Regards,
On Jul 1, 8:50 pm, cyanogen <steve.kon...@gmail.com> wrote:
> There's nothing wrong with my toolchain. This problem is reproducible
> by anyone who tries to build AOSP for Dream or Sapphire.
> On Jul 1, 4:12 am, Sean Hodges <seanhodge...@googlemail.com> wrote:
> > Is there a chance something, like a system update, might have
> > disturbed your toolchain?
> > Do other releases build for the Dream OK?
> > On Thu, Jul 1, 2010 at 1:33 AM, cyanogen <steve.kon...@gmail.com> wrote:
> > > Checked that, and I also added some extra debug code to print si->size
> > > in reserve_mem_region, and I can't see anywhere it's overrunning the
> > > prelink space. Something is fishy.
> > > On Jun 30, 4:51 pm, fadden <fad...@android.com> wrote:
> > >> On Jun 30, 11:11 am, cyanogen <steve.kon...@gmail.com> wrote:
> > >> > Thanks for the response. I checked this, but the alloted space in the
> > >> > prelink map is 2MB and the library in question is only 300k. The same
> > >> > problem happens with a different library (libaudio) and there is
> > >> > plenty of space for it as well. Everything is fine on Passion builds,
> > >> > it's only happening when building for Dream/Sapphire.
> > >> Did you check the library *below* the library that's failing? The
> > >> address-specific mmap() call would fail if another library had been
> > >> loaded below it and exceeded its bounds.
> > >> 0x40b0c000 is in the right area for a "next available" space
> > >> allocation. Looking at linker.c, we're not specifying MAP_FIXED, so
> > >> this behavior is expected.
> > > --
> > > You received this message because you are subscribed to the Google Groups "android-platform" group.
> > > To post to this group, send email to android-platform@googlegroups.com.
> > > To unsubscribe from this group, send email to android-platform+unsubscribe@googlegroups.com.
> > > For more options, visit this group athttp://groups.google.com/group/android-platform?hl=en.
> Checked that, and I also added some extra debug code to print si->size
> in reserve_mem_region, and I can't see anywhere it's overrunning the
> prelink space. Something is fishy.
> On Jun 30, 4:51 pm, fadden <fad...@android.com> wrote:
> > On Jun 30, 11:11 am, cyanogen <steve.kon...@gmail.com> wrote:
> > > Thanks for the response. I checked this, but the alloted space in the
> > > prelink map is 2MB and the library in question is only 300k. The same
> > > problem happens with a different library (libaudio) and there is
> > > plenty of space for it as well. Everything is fine on Passion builds,
> > > it's only happening when building for Dream/Sapphire.
> > Did you check the library *below* the library that's failing? The
> > address-specific mmap() call would fail if another library had been
> > loaded below it and exceeded its bounds.
> > 0x40b0c000 is in the right area for a "next available" space
> > allocation. Looking at linker.c, we're not specifying MAP_FIXED, so
> > this behavior is expected.
> Checked that, and I also added some extra debug code to print si->size
> in reserve_mem_region, and I can't see anywhere it's overrunning the
> prelink space. Something is fishy.
> On Jun 30, 4:51 pm, fadden <fad...@android.com> wrote:
> > On Jun 30, 11:11 am, cyanogen <steve.kon...@gmail.com> wrote:
> > > Thanks for the response. I checked this, but the alloted space in the
> > > prelink map is 2MB and the library in question is only 300k. The same
> > > problem happens with a different library (libaudio) and there is
> > > plenty of space for it as well. Everything is fine on Passion builds,
> > > it's only happening when building for Dream/Sapphire.
> > Did you check the library *below* the library that's failing? The
> > address-specific mmap() call would fail if another library had been
> > loaded below it and exceeded its bounds.
> > 0x40b0c000 is in the right area for a "next available" space
> > allocation. Looking at linker.c, we're not specifying MAP_FIXED, so
> > this behavior is expected.
It appears they have reorganized the prelink map in Froyo! Some of the
proprietary blobs date back to Donut and are hacked up in various ways
for our custom builds.
Rearranging the prelink map should do the job. There are other blobs
that need adjusted too.
On Jul 1, 9:25 am, aBiNg <cn.fyo...@gmail.com> wrote:
> You are right, my libspeech.so issue has been fixed.
> As for the liboemcamera.so issue, we have the exactly same problem.
> logcat is here:
> E/QualcommCameraHardware( 60): FATAL ERROR: could not dlopen
> liboemcamera.so: Cannot load library: reserve_mem_region[810]:
> OOPS: 60 prelinked library 'liboemcamera.so' mapped at
> 0x40d0c000, not at 0xa9400000
> The corresponding address of 0xa9400000 is referred to
> libvorbisidec.so library. Are they overlapped, as fadden said?
> And I read reports by other people that dynamic libraries would be
> inflated while being called. Is this true?
> Regards,
> On Jul 1, 8:50 pm, cyanogen <steve.kon...@gmail.com> wrote:
> > There's nothing wrong with my toolchain. This problem is reproducible
> > by anyone who tries to build AOSP for Dream or Sapphire.
> > On Jul 1, 4:12 am, Sean Hodges <seanhodge...@googlemail.com> wrote:
> > > Is there a chance something, like a system update, might have
> > > disturbed your toolchain?
> > > Do other releases build for the Dream OK?
> > > On Thu, Jul 1, 2010 at 1:33 AM, cyanogen <steve.kon...@gmail.com> wrote:
> > > > Checked that, and I also added some extra debug code to print si->size
> > > > in reserve_mem_region, and I can't see anywhere it's overrunning the
> > > > prelink space. Something is fishy.
> > > > On Jun 30, 4:51 pm, fadden <fad...@android.com> wrote:
> > > >> On Jun 30, 11:11 am, cyanogen <steve.kon...@gmail.com> wrote:
> > > >> > Thanks for the response. I checked this, but the alloted space in the
> > > >> > prelink map is 2MB and the library in question is only 300k. The same
> > > >> > problem happens with a different library (libaudio) and there is
> > > >> > plenty of space for it as well. Everything is fine on Passion builds,
> > > >> > it's only happening when building for Dream/Sapphire.
> > > >> Did you check the library *below* the library that's failing? The
> > > >> address-specific mmap() call would fail if another library had been
> > > >> loaded below it and exceeded its bounds.
> > > >> 0x40b0c000 is in the right area for a "next available" space
> > > >> allocation. Looking at linker.c, we're not specifying MAP_FIXED, so
> > > >> this behavior is expected.
> > > > --
> > > > You received this message because you are subscribed to the Google Groups "android-platform" group.
> > > > To post to this group, send email to android-platform@googlegroups.com.
> > > > To unsubscribe from this group, send email to android-platform+unsubscribe@googlegroups.com.
> > > > For more options, visit this group athttp://groups.google.com/group/android-platform?hl=en.
