headers
Peter Weilbacher | 2 Nov 2007 18:46

Re: emxomfar error: "Source library too big"

On 27.10.07 22:32, Yuri Dario wrote:
> Hi Peter,
> 
>>    emxomfar r docshell.lib nsDocShellModule.o
>> So, what else can this error message mean?
> 
> try adding -p xxx parameter, I need it for big libraries (e.g. -p 128)

Of course that was the first thing I tried. No help there. And as I said
the real big ones (113 MB) I can collect with emxomfar without problems,
just this one (less than 2 MB) makes problems. And obviously just for me
not for others who build Firefox... That's why I asked what this message
could really mean.

    Peter.
Permalink | Reply | 5 comments |
headers
Yuri Dario | 5 Nov 2007 23:42
Picon
Favicon

Re: emxomfar error: "Source library too big"

Hi Peter,

> just this one (less than 2 MB) makes problems. And obviously just for me
> not for others who build Firefox... That's why I asked what this message
> could really mean.

maybe you mixed aout and omf object files.

bye,

Yuri
Permalink | Reply | 4 comments |
headers
Peter Weilbacher | 6 Nov 2007 23:02

Re: emxomfar error: "Source library too big"

On 05.11.07 23:42, Yuri Dario wrote:

>> just this one (less than 2 MB) makes problems. And obviously just for me
>> not for others who build Firefox... That's why I asked what this message
>> could really mean.
> 
> maybe you mixed aout and omf object files.

Nice idea. I don't think so but while checking at least I noticed that one
of the .lib files was garbled. Not sure if that happened because I killed
a make when trying again, or if that was original. Will try to compile again.

    Peter.
Permalink | Reply | 3 comments |
headers
Peter Weilbacher | 7 Nov 2007 11:03

Re: emxomfar error: "Source library too big"

On 06.11.07 23:02, Peter Weilbacher wrote:
> On 05.11.07 23:42, Yuri Dario wrote:
> 
>>> just this one (less than 2 MB) makes problems. And obviously just for me
>>> not for others who build Firefox... That's why I asked what this message
>>> could really mean.
>>
>> maybe you mixed aout and omf object files.
> 
> Nice idea. I don't think so but while checking at least I noticed that one
> of the .lib files was garbled. Not sure if that happened because I killed
> a make when trying again, or if that was original. Will try to compile 
> again.

That didn't help, it's just that Veit's typos2 didn't output anything for
that .lib. listomf shows all the information for all of the files involved.

While trying all possible page sizes again (from 16 to 32768) I also noticed
that the error when using a too small page size is
    Library too big -- increase page size
not
    Source library too big
which is what I get...

    Peter.
Permalink | Reply | 2 comments |
headers
Yuri Dario | 7 Nov 2007 15:33
Picon
Favicon

Re: emxomfar error: "Source library too big"

Hi Peter,

> not
>     Source library too big
> which is what I get...

I looked at source code: the max number of pages in library files is 
hardcoded to 65536 when copying a library, see

libc-0.6\src\emx\src\libomflib\omflibcl.c

I doubled it and recompiled the emxomfar.exe tool, grab it here

http://web.os2power.com/emxomfar.exe

I only recompiled the code, so I didn't test it, but I think it should
work.

If it fixes your problem, let me know, I'll open a ticket and submit 
the patch.

cu,

Yuri
Permalink | Reply | 1 comment |
headers
Peter Weilbacher | 7 Nov 2007 23:46

Re: emxomfar error: "Source library too big"

On 07.11.07 15:33, Yuri Dario wrote:

> I looked at source code: the max number of pages in library files is
> hardcoded to 65536 when copying a library, see
> 
> libc-0.6\src\emx\src\libomflib\omflibcl.c
> 
> I doubled it and recompiled the emxomfar.exe tool, grab it here
> 
> http://web.os2power.com/emxomfar.exe
> 
> I only recompiled the code, so I didn't test it, but I think it should
> work.
> 
> If it fixes your problem, let me know, I'll open a ticket and submit
> the patch.

Many thanks, Yuri! Would never have found that in the sources... And
yes, it indeed fixed my problem and results in a Firefox build that
runs nicely. :-)

    Peter.
Permalink | Reply | 0 comments |
headers
James Moe | 17 Nov 2007 06:31
Favicon

Volatile structures


Hello,
  My application often has a lot of threads operating on the same data
set. Mutexes handle access to the data quite nicely.
  Almost always.
  Does the compiler copy structures to local thread memory for faster
manipulation before writing it back? And can that write-back operation be
interrupted to service another thread?
  What I see happening (in my log files), I conjecture, is that a
structure is being updated in one thread, but the changed data is NOT
showing up in another thread that accesses that data immediately thereafter.

--
jimoe (at) sohnen-moe (dot) com
Permalink | Reply | 9 comments |
headers
Paul Ratcliffe | 20 Nov 2007 20:26
Picon

Re: Volatile structures

On Fri, 16 Nov 2007 22:31:18 -0700, James Moe <jimoe <at> sohnen-moe.com> wrote:

>   My application often has a lot of threads operating on the same data
> set. Mutexes handle access to the data quite nicely.
>   Almost always.
>   Does the compiler copy structures to local thread memory for faster
> manipulation before writing it back?

No. How does copying data around result in faster operation?
It just doesn't happen.

> And can that write-back operation be
> interrupted to service another thread?

Almost anything can be interrupted in theory. There is no write-back though.

>   What I see happening (in my log files), I conjecture, is that a
> structure is being updated in one thread, but the changed data is NOT
> showing up in another thread that accesses that data immediately thereafter.

You should declare things as "volatile" then, to stop the optimizer from
caching things in registers.
Try a test build with optimization disabled to see if the problem goes away.
Permalink | Reply | 8 comments |
headers
James Moe | 21 Nov 2007 03:30
Favicon

Re: Re: Volatile structures


On 11/20/07 12:26 pm, Paul Ratcliffe wrote:
> 
>>   My application often has a lot of threads operating on the same data
>> set. Mutexes handle access to the data quite nicely.
>>   Almost always.
>>   Does the compiler copy structures to local thread memory for faster
>> manipulation before writing it back?
> 
> No. How does copying data around result in faster operation?
> It just doesn't happen.
> 
  I didn't think so. I was thrashing around for a grip on the problem.
  Specifically what was happening is the I have a container in details
view. The original code used the WinSendMsg() command CM_INSERTRECORD to
add one or more items to the container window. If more than one item, it
is expected to be a linked list using precNextRecord in the RECORDCORE
structure to link them together.
  What was happening was that when many threads were updating the list,
somehow that link entry was set to NULL even though I could trace the
execution and see that it should not have been. The random change always
occurred while the container window was being updated.
  I have since changed the window update method to CM_INSERTRECORDARRAY
and there is no longer a memory corruption problem. Also the list no
longer expects precNextRecord links to be valid; a separate link field is
now used and is never corrupted.

--
jimoe (at) sohnen-moe (dot) com
(Continue reading)

Permalink | Reply | 7 comments |
headers
Steven Levine | 22 Nov 2007 06:56
Picon
Favicon

Re: Re: Volatile structures

In <4743985A.4020709 <at> sohnen-moe.com>, on 11/20/07
   at 07:30 PM, James Moe <jimoe <at> sohnen-moe.com> said:

Hi,

>  What was happening was that when many threads were updating the list,
>somehow that link entry was set to NULL even though I could trace the
>execution and see that it should not have been. The random change always
>occurred while the container window was being updated.

This has all the indications of being a locking error.  If you really are
using WinSendMsg to send messages cross thread, you could very well have
confused PM.  Best I can tell, PM really does not expect more than one
thread to modifiy the contents of a container.  Note that using WinPostMsg
effectively ensures that the modifications are done by a single thread. 
It also serializes the operations and reduces the need for locking.

Steven

--

-- 
----------------------------------------------------------------------
"Steven Levine" <steve53 <at> earthlink.net>  MR2/ICE 3.00 beta 09pre #10183 eCS/Warp/DIY/14.103a_W4 etc.
www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
----------------------------------------------------------------------
Permalink | Reply | 6 comments |

Gmane