An open Writer Draw process will crash as well ...

Reproducible with "AOO 4.0.1 – German UI / German locale [Rev. 1524958 2013-09-20 11:40:29]" on German WIN7 Home Premium (64bit)", “historic” 4.0 User Profile used for all predecessor versions:

1. Open sample document from AOO Start Center
2. Click Chart
3. <control+c>
   Bug: MAximum Processor load, AOO stops responding

Additional Info
---------------
(a) Nothing special with the document, same with newly created chart (identical
    data ranges) in new document with data by copy / paste as plain text from
    reporter's sample

I will do some more research now

(b) at least part of the problem are the big numbers in column A. Reducing the 
    range 1 ... 16777216   to 1 ...5 heals the problem. Let's see ...

(c) already reproducible with server installation of " AOO 4.0.0-Dev – English 
    UI / German locale [AOO400m1(Build:9700) - Rev. 1457992 – Rev.1457606
    ((2013-03-19))]" on German WIN7 Home Premium (64bit)", 
    own separate user profile

(d) was still ok with 3.4.1

(e) Still Reproducible with server installation of "AOO 4.1.0-Dev – English UI 
   / German locale - [AOO410m1(Build:9750) - Rev. 1558977 - 2014-01-18]" 
   on German WIN7 Home Premium (64bit)", own separate user profile.

(f) It seems that diagram type does not matter, also with columns diagram

Confirmed also in 
AOO410m1(Build:9750)  -  Rev. 1557669
2014-01-14_04:11:13 - Rev. 1557927
Debian

I will look into this.

There are two parts of the core problem:
1. The horizontal axis is, when copied, treated as showing dates.
2.Invalid date or dates that lie far in the future are not handled very well.

In this case 2 is triggered by 1.

Re 2: The tools Date class is not well designed or implemented.  It stores the year modulo 10000 and does not report overrun.  This leads to a Date object created for the year 9426 (caused by 1).  When the tick marks for the axis are created the next tick mark is created 582 years in the future.  The resulting year modulo 10000 is 8.  That is marked invalid because it is before the 'beginning of time', October 15th 1582 (start of the gregorian calendar).

The DateHelper class in the chart2/ module tries to handle the invalid date by repeatedly decreasing it (by one day) until it becomes valid again.  This never happens, and thus the infinite loop.
Fixing this reveals a similar bug in DateTickFactory::getAllTicks() that again loops until a date reaches an upper bound and does not take into account that date+n < date.
After fixing this, too, I can finally copy the chart.  Pasting it reveals that the axes have different ranges and that the horizontal axis shows dates as ticks.

So, I have to find why the axis is suddenly using dates to fix item 1.

I am supporting Andre on the "bug hunting" and together we have found out the following:
- Until version 4.0.0 the copy of charts on 'Sheet1' are treated differently than on the other sheets - see bug 118840
- creating the same chart as in the given sample on 'Sheet2' and try to copy it causes the same loop in AOO 3.4.0 and AOO 3.4.1 as in AOO 4.0.0 for 'Sheet1', but still works in OOo 3.3.0 and OOo 3.4.0Beta
- copying charts in OOo versions (3.4.0Beta, 3.3.0 and earlier) just works.

Problem 1 (horizontal axis shows dates) has also two components:

A) A general problem with the horizontal (X) axis (Y and Z axis are treated specially and differently) leads to use dates for its tick marks whenever possible.  And that seems to be most of the time.

B) A) is triggered by a) copying the chart (to clipboard) and b) it having an internal data provider.

Details:  Copying the chart starts with a call do ScDrawView::DoCopy().  This leads eventually to a call to chart::AxisHelper::getExplicitNumberFormatKeyForAxis().  Other methods on the call stack are: ChartHelper::tryToGetChartContentAsPrimitive2DSequence(), chart::ChartView::update(), chart::ChartView::createShapes().

In getExplicitNumberFormatKeyForAxis() the XPropertySet of the axis returns 0 at first.  This would lead to exactly the desired formatting (plain numbers).  But when the chart document has an internal data provider then the number format is updated by this code snippet (AxisHelper.cxx:187, reformatted):
  else if( xChartDoc.is() && xChartDoc->hasInternalDataProvider()
     && nDimensionIndex == 0 ) //maybe date axis
  {
     Reference< chart2::XDiagram > xDiagram( xChartDoc->getFirstDiagram() );
     if( DiagramHelper::isSupportingDateAxis( xDiagram ) )
     {
       nNumberFormatKey = DiagramHelper::getDateNumberFormat( 
         xNumberFormatsSupplier );
     }
     ...

isSupportingDateAxis returns true. It does that for the majority of chart types and, more importantly, it does that with checking the chart type and otherwise only static data.  If the user sets the axis type explicitly to, say, text, then that is ignored.
That means, the pure existence of the internal data provider causes the bug, not any of the values it does provide.

Created attachment 82375 [details]
Chart in text document

Chart in text document (data is contained in a table owned by the chart).
Copying this chart works as expected, even when it is copied into the Calc document.

The code described in the previous comment is executed as well.  Apparently the number format is set to a different (correct) value later.

Another data point on our way to a solution:

As was observed earlier, the presence of the internal data provider in lcl_fillDateCategories (chart2/source/tools/ExplicitCategoriesProvider.cxx) leads to bIsDate being set to true for all values of the horizontal axis.

But a little later there is this code (reformatted):

  DatePlusIndex aDatePlusIndex( 1.0, nN );
  if( bIsDate && (aAny >>= aDatePlusIndex.fValue) )
      rDateCategories.push_back( aDatePlusIndex );
  else
  {
      if( aAny.hasValue() && !bContainsEmptyString )//empty string does not count as non date value!
          bOnlyDatesFound=false;
      ::rtl::math::setNan( &aDatePlusIndex.fValue );
      rDateCategories.push_back( aDatePlusIndex );
  }

bDate only has an effect when the values in the label column (labels of the x axis) can be streamed into a variable of type double.  And that reveals the big difference in the charts in the two bug docs.  The chart in the Calc document interprets the values in the label column as numbers and streaming them into a double variable succeeds, while the chart in the Writer documents has its own internal data table, that declares the type of its labels as String.  They can not be streamed into doubles and thus no conversion into dates.

A workaround for the problem is to convert the values in the first column to text.  Changing just the format is not enough.  Is there an easier way to change the cell type than, eg adding a leading or trailing space?

"af" committed SVN revision 1560934 into trunk:
124069: Prevent infinite loop when looking too far into the future.

I have checked in changes that prevent the infinite loop.  However, the copied charts look different from the original.  Not only because the labels are formatted as dates but because during the conversion of numbers to dates information is lost (year values are stored modulo 10000).

I have create bug 124100 for the different axis type after copy and paste.

I am setting this bug to resolved/fixed because the problem described in its title is fixed.

Verified on snapshot Rev.1566593, the defect was resolved.

Change defect status per Clarence Guo's comment