Re: why does this core dump on solaris and not on linux
From: You have no need to know (anjahnoaoed_at_fl.net.invalid)
Date: 05/29/05
- Next message: franzaklein_at_yahoo.co.uk: "Bootsect.S differences between 2.4.20 and 2.6.10"
- Previous message: Peter T. Breuer: "Re: Error: Invalid Module format"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 29 May 2005 07:02:51 GMT
Abandoning the right to remain silent, nin234 at Wed, 19 Jan 2005 13:36:25
-0800 said:
> I am using system shared memory techniques, like shmget, shmat etc to
> create a shared memory segment and manipulate data. I get a core dump
> (SIGSEGV) when I run the daemon on Solaris. The same program works fine
> on Red hat enterprise linux.
If by "on Solaris" you mean "on Sparc hardware" you have to get alignment
right. If your code specifies an aligned object (e.g. pointer) it had
better be aligned correctly. Otherwise you *will* get core dumps.
> Here is the relevant section of code causing the problem.
>
> probeSession *pSession = reinterpret_cast<probeSession *>(shmStart +
>
> nO ffset);
>
> util::utilLog(ePROBE_LOG_ERROR, "Failed to %d. \n",
> pSession->captureRuleIndex)
>
> The access to the shared memory variable pSession->captureRuleIndex is
> the culprit.
So if pSession&0x03 != 0 (32 bit mode or 0x07 in 64 bit mode) you will get
a dump.
> Even on Solaris if i do as follows, It works fine.
>
> int nTest;
>
> memcpy (&nTest, &(pSession->captureRuleIndex), sizeof (int));
>
> util::utilLog(ePROBE_LOG_ERROR, "Failed to %d. \n", nTest);
memcpy has char parameters, so alignment does not matter. When you
reference the memcpy'd object it had better be correctly aligned.
> I want to avoid the memcpy for performance reasons. In the real world I
> want to access the entire struct (probeSession) which is about 1264
> bytes . So memcpy is an expensive operation for a real time packet
> capture system that I am working on.
>
> Ninan
-- Avoid reality at all costs. $email =~ s/n(.)a(.)n(.)a(.)e(.+)invalid/$1$2$3$4$5au/; icbm: 33.43.46S 150.59.27E
- Next message: franzaklein_at_yahoo.co.uk: "Bootsect.S differences between 2.4.20 and 2.6.10"
- Previous message: Peter T. Breuer: "Re: Error: Invalid Module format"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|