Value too large for defined data type...
in [Solaris]
|
From: maps on 30 Dec 2009 10:38 > Given that this used to work and now doesn't in more than one case, > and that the error doesn't make sense to me, I wonder if something got > screwed up on the system. Seems very odd to me. We've been wondering the same; and no one has been able to resolve it so far. I am wondering how do we move beyond this point ? How do we dig deeper ? or backtrace, maybe ? -maps.
From: Darren Dunham on 30 Dec 2009 12:01 On Dec 30, 7:38 am, maps <mapsiddi...(a)gmail.com> wrote: > > Given that this used to work and now doesn't in more than one case, > > and that the error doesn't make sense to me, I wonder if something got > > screwed up on the system. Seems very odd to me. > > We've been wondering the same; and no one has been able to resolve it > so far. I am wondering how do we move beyond this point ? How do we > dig deeper ? or backtrace, maybe ? > > -maps. Get another system. Try the same commands there. If it works, something on your current system is screwed up. Consider reinstalling. If the same commands don't work on another system (and fail in the same way), then we're all missing something. Report back. If you don't have other hardware, do you have anything that would run VMware or Virtualbox? Maybe you could spin up a Solaris virtual machine pretty quickly to try as another data point. -- Darren
From: maps on 30 Dec 2009 14:18 > Get another system. Try the same commands there. If it works, > something on your current system is screwed up. Consider > reinstalling. Works on other systems. Interestingly on one of the other system fstat with the same parameters works. I tried this on another server having solaris 10 and the command runs just fine. > If you don't have other hardware, do you have anything that would run > VMware or Virtualbox? Maybe you could spin up a Solaris virtual > machine pretty quickly to try as another data point. Maybe but the problem is we dont understand where the problem is originating from and unless we do so it may not be possible to recreate the problem. -maps.
From: Richard B. Gilbert on 30 Dec 2009 14:32 maps wrote: > 0.0178 fstat(0, 0x00028C28) Err#79 > EOVERFLOW > > This is probably the root cause of the issue. But then we already had > guessed it earlier; so how can this problem be resolved now ? Do I assume that 0.0178 is a line number rather than a part of the fstat call? Where did the value 0x00028C28 come from? I assume it's a pointer to something, but what? I really don't want to try to go back to the beginning of this thread in order to make sense of your post. Try posting a "reproducer"; e.g. reproduce the error with fewer than, say, fifteen lines of code.
From: maps on 30 Dec 2009 14:44
> Do I assume that 0.0178 is a line number rather than a part of the fstat > call? Where did the value 0x00028C28 come from? I assume it's a > pointer to something, but what? thats the timestamp from truss output; it wasnt a part of the fstat call. > I really don't want to try to go back to the beginning of this thread in > order to make sense of your post. Try posting a "reproducer"; e.g. > reproduce the error with fewer than, say, fifteen lines of code. Well this error didnt come up while executing a code. It started appearing all of a sudden on one of our production servers whenever we used a pipe ( | ). In the specific case I quoted above, it occurred in the following manner : zcat foo.txt.Z | diff foo.txt - diff: stdin: value too large for defined data type. -maps. |