Bug 134757

Summary: 32 bit processes on 64 bit platforms occasionally drop core with bad ds reg
Product: Base System Reporter: Stephen Sanders <ssanders>
Component: amd64Assignee: freebsd-amd64 (Nobody) <amd64>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.txt
none
ssanders.vcf none

Description Stephen Sanders 2009-05-20 17:00:12 UTC
With fair regularity, we have 32 bit processes dropping core on 64 bit systems.  In particular perl and bash.

Our system is definitely a hybrid but that aspect appears to not be the issue.  The system works properly more than not.

I have attached a file containing 2 gdb sessions. One session is looking at a core that bash left behind and the other is looking at a bash session with no core.

In the core case, the core drop is occurring when the instruction "cmpl $0x0,,0x80d41d4" is executed.  Checking the registers, one will see that 

ss == cs == ds == es == fs == gs == 0x23 35

In the non-core case, I halted execution on execute_command() and found that 

ss == 0x23 35

ds == es == fs == gs == 0x0

This sound suspiciously like a bug that was fixed in 7.1.  I believe the issue was in in cpuswitch.S.

Porting the 32 bit processes up to 64 bits is not currently an option for a solution.

Fix: None.

Patch attached with submission follows:
How-To-Repeat: Fork a 32 bit process on a 64 bit 6.3 FBSD machine often and long enough.  Something like once a minute.

Alternatively, fork a large number of 32 bit processes at boot time.
Comment 1 John Baldwin freebsd_committer freebsd_triage 2009-05-21 17:21:00 UTC
Have you tested this on 7 at all?  At this point most developers are probably 
much more inclined to fix this for 8.0 and 7.x rather than 6.x.

-- 
John Baldwin
Comment 2 Stephen Sanders 2009-05-21 17:31:01 UTC
I've not tried this under 7.x yet but do plan on doing so within the
next few weeks or so.

Unfortunately, I'm sort of stuck with this 6.3 32 bit/64 bit 
arrangement for the next 6 months or more as we've a number of systems
deployed.

Thanks for the reply.
Comment 3 Andriy Gapon freebsd_committer freebsd_triage 2010-12-05 13:58:20 UTC
State Changed
From-To: open->closed

The submitter has not been able to reproduce the problem 
with 7.x or 8.x.  At least, that's how I interpret the 
absence of any followups.
Comment 4 Stephen Sanders 2010-12-06 15:06:23 UTC
We've been testing using 8.1 and have not run into this problem.  I'm
thinking that this bug can be retired.

Thanks