Ask a Question related to AIX, Design and Development.
-
Mr T #1
SEGV when lazy loading!
I'm getting a core when lazy loading one of my libraries I build with:
-bexpall
but NOT when I manually export the symbols using -E$(MODULE).exp
Can anyone explain why?
Is there a symbol table limit when lazy loading?
TIA
Simon Temple
UK.
/lzld/ Calling lazy function 'pthread_init()'>run
/lzld/ searching in module 'libpthreads.a(shr_xpg5.o)'
/lzld/ Loaded module '/usr/lib/libpthreads.a'
/lzld/ Calling lazy function 'pthread_attr_init()'
/lzld/ searching in module 'libpthreads.a(shr_xpg5.o)'
/lzld/ Calling lazy function 'pthread_mutexattr_init()'
/lzld/ searching in module 'libpthreads.a(shr_xpg5.o)'
/lzld/ Calling lazy function 'pthread_attr_setdetachstate()'
/lzld/ searching in module 'libpthreads.a(shr_xpg5.o)'
/lzld/ Calling lazy function 'pthread_mutex_lock()'
/lzld/ searching in module 'libpthreads.a(shr_xpg5.o)'
/lzld/ Calling lazy function 'pthread_mutex_unlock()'
/lzld/ searching in module 'libpthreads.a(shr_xpg5.o)'
/lzld/ Calling lazy function 'ReadInternationalTextMsg()'
/lzld/ searching in module 'libreims_r.a()'
/lzld/ Loaded module '/olympus/home/spt/work/r4.3/libreims/libreims_r.a'
Memory fault(coredump)
Segmentation fault in lazyInitModule at 0xd120c8c8>dbx
0xd120c8c8 (lazyInitModule+0x214) 7cc6382e lwzx r6,r6,r7
(dbx) where
lazyInitModule(??, ??, ??) at 0xd120c8c8
lazyLoadModule(??, ??) at 0xd120c5e4
__lazyResolve(??, ??) at 0xd120cebc
lazyload.__lazyload() at 0x208f1fd4
DBAPIInitialise(), line 104 in "fdbinit.c"
Mr T Guest
-
#39280 [NEW]: Support for lazy evaluation type
From: arendjr at gmail dot com Operating system: All PHP version: 5.1.6 PHP Bug Type: Feature/Change Request Bug... -
TMM Volunteers = Miss Congeniality.....correction: LAZY
Just looking at the all these TMM Volunteers' own personal websites and they seem lack luster in quality. I can't see how these people can be... -
Lazy Loading Objects
I use an OOP design pattern by Martin Fowler called Lazy Load. In this pattern, an object loads some of its properties on initialization and loads... -
Stop Being Lazy!
OK. A lot of the time you will see new threads being spawned off old ones on this list. This is very annoying if you have a mailer (mutt) that... -
Do triggers use *lazy* OR ?
I don't believe it will execute the OR if the first expression is true. But you can test it easy enough by making the UDF error if called and run... -
Gary R. Hook #2 Re: SEGV when lazy loading!
Mr T wrote:
Very, very odd. I take it this is easily recreatable?> I'm getting a core when lazy loading one of my libraries I build with:
> -bexpall
> but NOT when I manually export the symbols using -E$(MODULE).exp
>
> Can anyone explain why?
No, the code counts the number of exports in the module,> Is there a symbol table limit when lazy loading?
and bases its work on that value.
Just out of curiosity, is there a clear difference in
the list of exports when you use -bexpall vs. -E? The
dump -HTv command output is useful here, with some
awking and filtering...
Also, what is your build command? C++ or other languages?
What OS level? lslpp -l bos.rte.bind_cmds output?
I would suggest reporting the problem to your support
organization, but in the meantime it might be interesting
to see the register values (the dbx 'x' command). The
offending instruction below is accessing the first word
of a function descriptor, so the question is, what addresses
are in use? And where is the module located (the relevant
portions of the dbx 'map' command)?
--> Segmentation fault in lazyInitModule at 0xd120c8c8
> 0xd120c8c8 (lazyInitModule+0x214) 7cc6382e lwzx r6,r6,r7
> (dbx) where
> lazyInitModule(??, ??, ??) at 0xd120c8c8
> lazyLoadModule(??, ??) at 0xd120c5e4
> __lazyResolve(??, ??) at 0xd120cebc
> lazyload.__lazyload() at 0x208f1fd4
> DBAPIInitialise(), line 104 in "fdbinit.c"
Gary R. Hook / AIX PartnerWorld for Developers / These opinions are MINE
__________________________________________________ ______________________
Gary R. Hook Guest
-
Mr T #3 Re: SEGV when lazy loading!
Gary
-------------------------------------------------------------------------
The library I export all symbols from by generating an export file using:
/usr/vacpp/bin/CreateExportList
3696>dump -THv *.a | grep EXP | wc -l
The library I restrict the symbols using an manually created export file:
1411>dump -THv *.a | grep EXP | wc -l
This is the one that works!
A symbol count difference of:
2285
-------------------------------------------------------------------------4.3.3.0> oslevel
-------------------------------------------------------------------------
Fileset Level State Description> lslpp -l bos.rte.bind_cmds
-------------------------------------------------------------------------
Path: /usr/lib/objrepos
bos.rte.bind_cmds 4.3.3.77 COMMITTED Binder and Loader
-------------------------------------------------------------------------
I'm using /usr/vacpp/bin/makeC++SharedLib_r to build the library.
I get the same problems with -bexpall or using the file I generate
using CreateExportList.
-------------------------------------------------------------------------
(dbx) where
lazyInitModule(??, ??, ??) at 0xd00e08c8
lazyLoadModule(??, ??) at 0xd00e05e4
__lazyResolve(??, ??) at 0xd00e0ebc
lazyload.__lazyload() at 0xd2151ff0
DBAPIInitialise(), line 104 in "fdbinit.c"
main(argc = 2, argv = 0x2ff203e8), line 106 in "etsxmcl.c"
(dbx) x
$r0:0x00808000 $stkp:0x2ff1fd58 $toc:0xf03312e0 $r3:0x20184b28
$r4:0x20501ae0 $r5:0x0000004e $r6:0x00425938 $r7:0x200dc1a8
$r8:0x00000000 $r9:0x5f00002b $r10:0x00808000 $r11:0x7f7f7f7f
$r12:0xd6e4380d $r13:0xdeadbeef $r14:0x00000002 $r15:0x2ff203e8
$r16:0x2ff203f4 $r17:0x00000000 $r18:0xdeadbeef $r19:0xdeadbeef
$r20:0xdeadbeef $r21:0xd21e7b34 $r22:0x00000004 $r23:0xd21e7da1
$r24:0xd21e7da1 $r25:0x00000000 $r26:0x2000a3a8 $r27:0xd6df0718
$r28:0xd6ded800 $r29:0xd6e437bf $r30:0xd6df0726 $r31:0x00000a36
$iar:0xd00e08c8 $msr:0x0000d0b2 $cr:0x44222444 $link:0xd00e08b0
$ctr:0x00000000 $xer:0x20000000
Condition status = 0:g 1:g 2:e 3:e 4:e 5:g 6:g 7:g
[unset $noflregs to view floating point registers]
in lazyInitModule at 0xd00e08c8 ($t1)
0xd00e08c8 (lazyInitModule+0x214) 7cc6382e lwzx r6,r6,r7
(dbx) map
Entry 1:
Object name: etsxmcl
Text origin: 0x10000000
Text length: 0x120d91
Data origin: 0x20000020
Data length: 0x9289
File descriptor: 0x5
Entry 2:
Object name: /olympus/home/reims-v4.3/system/aix/lib/libx25s.a
Member name: shr.o
Text origin: 0xd20f10f8
Text length: 0xfe5
Data origin: 0x2001f7cb
Data length: 0x329
File descriptor: 0x6
Entry 3:
Object name: /usr/lib/libi18n.a
Member name: shr.o
Text origin: 0xd0a08100
Text length: 0x7adc
Data origin: 0x200206d0
Data length: 0x112c
File descriptor: 0x7
Entry 4:
Object name: /usr/lpp/X11/lib/R5/libXm.a
Member name: shr4.o
Text origin: 0xd1dbe100
Text length: 0x1ccff8
Data origin: 0x20022400
Data length: 0x2f5bc
File descriptor: 0x8
Entry 5:
Object name: /usr/lpp/X11/lib/R5/libX11.a
Member name: shr4net.o
Text origin: 0xd20f32e8
Text length: 0x6b5
Data origin: 0x200526e8
Data length: 0x88
File descriptor: 0x9
Entry 6:
Object name: /usr/lib/libIM.a
Member name: shr.o
Text origin: 0xd09fc100
Text length: 0x4f5f
Data origin: 0x20053df8
Data length: 0x84c
File descriptor: 0xa
Entry 7:
Object name: /usr/lib/libiconv.a
Member name: shr4.o
Text origin: 0xd014e100
Text length: 0x13f3a
Data origin: 0x20055da0
Data length: 0xa574
File descriptor: 0xb
Entry 8:
Object name: /usr/lpp/X11/lib/R5/libX11.a
Member name: shr4.o
Text origin: 0xd2052100
Text length: 0x9e263
Data origin: 0x20061438
Data length: 0x43fa8
File descriptor: 0xc
Entry 9:
Object name: /usr/lpp/X11/lib/R5/libXt.a
Member name: shr4.o
Text origin: 0xd1c45d80
Text length: 0x5055f
Data origin: 0x200a6418
Data length: 0xbb0c
File descriptor: 0xd
Entry 10:
Object name: /olympus/home/reims-v4.3/system/aix/lib/libIXXML4C.a
Text origin: 0xd2204000
Text length: 0x12659e
Data origin: 0x200b25f0
Data length: 0x299f8
File descriptor: 0xe
Entry 11:
Object name: /olympus/home/reims-v4.3/system/aix/lib/libreims.a
Text origin: 0xd6777000
Text length: 0x6f3bef
Data origin: 0x200dc1a8
Data length: 0xa586c
File descriptor: 0xf
Entry 12:
Object name: /usr/lib/libpthreads.a
Member name: shr_xpg5.o
Text origin: 0xd0004000
Text length: 0x20307
Data origin: 0x2001a000
Data length: 0x400c
File descriptor: 0x10
Entry 13:
Object name: /olympus/home/spt/work/r4.3/libdbapi/libdbapi_r.a
Text origin: 0xd20f4000
Text length: 0xf48de
Data origin: 0xf03345e0
Data length: 0x3e70
File descriptor: 0x11
Entry 14:
Object name: /usr/lib/librtl.a
Member name: lazy42.o
Text origin: 0xd00e0180
Text length: 0x25d3
Data origin: 0xf03311c0
Data length: 0x26a8
File descriptor: 0x12
Entry 15:
Object name: /usr/lib/libc.a
Member name: pse.o
Text origin: 0xd014d522
Text length: 0xa49
Data origin: 0xf0139522
Data length: 0x0
File descriptor: 0x13
Entry 16:
Object name: /usr/lib/libtli.a
Member name: shr.o
Text origin: 0xd0124920
Text length: 0x883b
Data origin: 0xf0137088
Data length: 0x13a8
File descriptor: 0x14
Entry 17:
Object name: /olympus/home/reims-v4.3/system/aix/lib/libIXXML4C_r.a
Text origin: 0xd232b000
Text length: 0x1265b3
Data origin: 0xf0bc75e8
Data length: 0x299f8
File descriptor: 0x15
Entry 18:
Object name: /usr/lib/libC.a
Member name: shr3.o
Text origin: 0xd0b5b940
Text length: 0x678d
Data origin: 0xf0318340
Data length: 0xcb8
File descriptor: 0x16
Entry 19:
Object name: /usr/lib/libC.a
Member name: ansi_32.o
Text origin: 0xd0a42ec0
Text length: 0x10ebf8
Data origin: 0xf03004c0
Data length: 0x15870
File descriptor: 0x17
Entry 20:
Object name: /usr/lib/libC.a
Member name: shr.o
Text origin: 0xd0a10100
Text length: 0x311f8
Data origin: 0xf02fb700
Data length: 0x3ff4
File descriptor: 0x18
Entry 21:
Object name: /usr/lib/libC.a
Member name: shr2.o
Text origin: 0xd0b52700
Text length: 0x807d
Data origin: 0xf0316f00
Data length: 0xaac
File descriptor: 0x19
Entry 22:
Object name: /olympus/home/spt/work/r4.3/libreims/libreims_r.a
Text origin: 0xd6e6b000
Text length: 0x8b39e5
Data origin: 0xf0a7e2f8
Data length: 0xc2b84
File descriptor: 0x1a
Entry 23:
Object name: /usr/lib/libpthreads.a
Member name: shr_comm.o
Text origin: 0xd0001000
Text length: 0x22b4
Data origin: 0xf0085000
Data length: 0x41004
File descriptor: 0x1b
Entry 24:
Object name: /usr/lib/libcrypt.a
Member name: shr.o
Text origin: 0xd00250f8
Text length: 0x87a
Data origin: 0xf0084528
Data length: 0x13c
File descriptor: 0x1c
Entry 25:
Object name: /usr/lib/libc.a
Member name: shr.o
Text origin: 0xd016dbe0
Text length: 0x1d5faf
Data origin: 0xf0000400
Data length: 0x83b08
File descriptor: 0x1d
-------------------------------------------------------------------------
"Gary R. Hook" <nospam@nospammers.net> wrote in news:Gao9b.320
$3P1.606103830@newssvr11.news.prodigy.com:
> Mr T wrote:
>>>> I'm getting a core when lazy loading one of my libraries I build with:
>> -bexpall
>> but NOT when I manually export the symbols using -E$(MODULE).exp
>>
>> Can anyone explain why?
> Very, very odd. I take it this is easily recreatable?
>>>> Is there a symbol table limit when lazy loading?
> No, the code counts the number of exports in the module,
> and bases its work on that value.
>
> Just out of curiosity, is there a clear difference in
> the list of exports when you use -bexpall vs. -E? The
> dump -HTv command output is useful here, with some
> awking and filtering...
>
> Also, what is your build command? C++ or other languages?
> What OS level? lslpp -l bos.rte.bind_cmds output?
>
> I would suggest reporting the problem to your support
> organization, but in the meantime it might be interesting
> to see the register values (the dbx 'x' command). The
> offending instruction below is accessing the first word
> of a function descriptor, so the question is, what addresses
> are in use? And where is the module located (the relevant
> portions of the dbx 'map' command)?
>>>> Segmentation fault in lazyInitModule at 0xd120c8c8
>> 0xd120c8c8 (lazyInitModule+0x214) 7cc6382e lwzx r6,r6,r7
>> (dbx) where
>> lazyInitModule(??, ??, ??) at 0xd120c8c8
>> lazyLoadModule(??, ??) at 0xd120c5e4
>> __lazyResolve(??, ??) at 0xd120cebc
>> lazyload.__lazyload() at 0x208f1fd4
>> DBAPIInitialise(), line 104 in "fdbinit.c"Mr T Guest
-
Mr T #4 Re: SEGV when lazy loading!
Just an update
--------------
I just updated the binder but the problem still exists!
-------------------------------------------------------------------------Fileset Level State Description> lslpp -l bos.rte.bind_cmds
-----------------------------------------------------------------------
Path: /usr/lib/objrepos
bos.rte.bind_cmds 4.3.3.80 COMMITTED Binder and Loader
-------------------------------------------------------------------------
TIA
Simon
Mr T Guest
Reply With QuoteSimilar Questions and Discussions
Posting Permissions
- You may not post new threads
- You may post replies
- You may not post attachments
- You may not edit your posts
