Tru64 5.1a msync causes corrupt files (sometimes)

Tru64 5.1a msync causes corrupt files (sometimes)

Post by Jake Sto » Fri, 20 Jun 2003 11:25:19



Hi All,

I've experienced a situation using the c function msync() where the
function returns successfully but the file being mapped has been
corrupted (file changed but extra bytes set to zero). This doesn't
happen everytime it varies from 1 in 5 times to 2 out of 3 times.

Has anyone seen this behaviour before?
I've tried changing some(most) of the dynamic kernel options using the
kernel tuner and recompiled the kernel with various options, tried the
mapped file on advfs and ufs, applied the latest accumulative patch
kit, searching for similar problems, to no avail...

Am I sure that it's the msync() function?
Yes. Using ladebug and confirming that what's in the mapped memory is
ok, as soon as the msync function returns the file is either corrupt
or good.

What does the application do?
In my test case (approximately);
 creates a private memory map of files A,B,C which are about 5MB in
size
 modifies a couple of the private memory maps (e.g A & B)
  creates a shared memory map for A
  bcopy's the modified private map to the shared map for A
  msync shared map A
  munmap shared map A
  munmap private map A
 repeat for other modified private maps

Any help, suggestions or comments would be greatly appreciated.

Regards,
Jake.

 
 
 

Tru64 5.1a msync causes corrupt files (sometimes)

Post by Jake Sto » Thu, 03 Jul 2003 16:35:21


So, judging from the response I guess no-one has run into a similar problem...

Is there a more appropriate forum for such a question?

Regards,
Jake.


> Hi All,

> I've experienced a situation using the c function msync() where the
> function returns successfully but the file being mapped has been
> corrupted (file changed but extra bytes set to zero). This doesn't
> happen everytime it varies from 1 in 5 times to 2 out of 3 times.

> Has anyone seen this behaviour before?
> I've tried changing some(most) of the dynamic kernel options using the
> kernel tuner and recompiled the kernel with various options, tried the
> mapped file on advfs and ufs, applied the latest accumulative patch
> kit, searching for similar problems, to no avail...

> Am I sure that it's the msync() function?
> Yes. Using ladebug and confirming that what's in the mapped memory is
> ok, as soon as the msync function returns the file is either corrupt
> or good.

> What does the application do?
> In my test case (approximately);
>  creates a private memory map of files A,B,C which are about 5MB in
> size
>  modifies a couple of the private memory maps (e.g A & B)
>   creates a shared memory map for A
>   bcopy's the modified private map to the shared map for A
>   msync shared map A
>   munmap shared map A
>   munmap private map A
>  repeat for other modified private maps

> Any help, suggestions or comments would be greatly appreciated.

> Regards,
> Jake.


 
 
 

1. Problem with libXm.so file of OSF Tru64 5.1A

Hi All,

I am facing a problem with OSF 5.1A libXm.so file.
If I run my test program with OSF Tru64 5.1A  , I am getting the
coredump.
The error message is :-

0x3ff8079378c in UnknownProcedure17FromFile83(0x1401c2050,
        0x0,0xfffffffffffffffb, 0x11fff6800, 0x3ffc01d3830, 0x1fff) in
/usr/shlib/libXm.so
        #1  0x3ff80793274 in UnknownProcedure16FromFile83(0x1401c2050,
      0x0,   0xfffffffffffffffb, 0x11fff6800, 0x3ffc01d3830, 0x1fff)
in /usr/shlib/libXm.so

But if I run my test program with OSF 5.1 libXm.so ( coping Tru64 5.1
libXm.so file ) , It's working fine (I am not getting the coredump ).
Please help me.
Is there any different Newsgroup for OSF Xmotif ? If so, please let me
know.

Thans in advance.

Regards
Prakash G.

2. Exceeded CPU time limit(coredump)

3. Netatalk sometimes corrupt files (Okbyte)!

4. Hardware Array Controllers

5. Sol2.3 tar corrupts extracted files if 'v' used with stdin, *sometimes*

6. Linux Dial In

7. vfs_mountroot panic on tru64 v5.1A

8. sysinfo()

9. Tru64 5.1A LUNs greater then 0 not found.

10. Tru64 5.1a and LX164 SRM Console

11. Perl/Tk on Tru64 5.1A

12. some prob with RA3000 and tru64 5.1A

13. C++ Compiler version and issues on TRU64 5.1A (upgrading from V4.0D)