I achieved the same result by entering 'a' in the Pages field.

I followed the steps given above and was able to successfully replicate the bug on Windows 7 Ultimate SP1. The same bug was also achieved when the number entered in 'Pages' text box exceeded the actual number of pages of content in the document. 

I got the same end result: The error message appeared only after user was prompted to save the file. After closing Writer, the Document Recovery dialog opened with recovery list being empty.

Tested on Macintosh & Windows 7

I was able to replicate the bug successfully in both Macintosh & Windows 7

Steps that I followed:

1. Create a .odt document.
2. Select the "Export as pdf" option in File menu
3. Select the pages radio button.
4. Enter 0 or any invalid input like 'a', '%Yu',67ui8, etc.,
5. a. Actual Behavior in Windows 7: 
      Open office crashes diplaying a dialog box saying "Due to an unexpected    error, Openoffice.org crashed". The dialog box does not close after clicking the close button. It will be closed only if we hit ok button.
   b. Actual Behavior in Macintosh:
      Open office crashes displaying a dialog box saying "Openoffice.org quit unexpectedly"
6.Exptected Behavior : Input validation procedures should not accept the invalid input like 0 'a' '%Yu' 67ui8 etc., The exceptions on the invalid input should be handled properly by showing the proper messages to the end user.
7. However, in both the cases, the .odt file could not be exported to pdf though it asks to enter the filename to be saved as when we are using this feature.

I tested the bug on Windows 7 professional and Mac OS and could successfully replicate the bug on both.
The steps I followed are--
1) Open a Writer document containing at least one page of content.
2) Go to File -->Export as PDF.
3) Select the Pages radio button.
4) Enter 0 and click on Export.
The same result is observed when a non-digit character like a, %,$,#,( etc or a number exceeding the existing number of pages is given.

Result expected: Invalid inputs such as 0, a, number exceeding the actual number of pages should be rejected and a appropriate warning message should be displayed to the user. 

Actual result:
(i) In the Windows OS, a 'save as' dialog box opened, prompting me to enter a filename. When I clicked the 'save' button, an error message popped up saying,"Error saving the document MyFile: Write Error. The file could not be written". After closing the writer,a document recovery dialog box appeared with the Files to be recovered list empty.
(ii)In the Mac OS,Open office crashed suddenly displaying an error message "Openoffice.org quit unexpectedly".

Confirming
Setting CRASH keyword

Created attachment 79698 [details]
GDB backtrace

Steps to get that backtrace:

- Create a new Writer document
- File - Export as PDF...
- On the PDF export dialog, tab "General", "Range", "Pages", enter 0
- Export
- After selecting the file name, you get a "Write error" error box
- close the Writer document (via the menu bar close or File - Close, it's the same)
- Crash

Adjusting platform (reproducible on Win, Linux, MacOS)
Adjusting component: cannot reproduce in Draw or Calc

ALG: Taking a look. Could reproduce the crash, taking a look what happens with this given zero (main/filter as it seems).

ALG: Problem seems to be that '0' in PageRange is an invalid data entry (Pages start at 1). The string is parsed late (inside the export filter) and the missing part seems to be a adequate reaction on a wrong PageRange definition.

ALG: Tried to avoid calling ExportSelection in PDFExport::Export when no pages are to be exported (there is already an if(nPageCount)). This does not work since in PDFExport::ExportSelection in the rRenderable->render call which triggers SwXTextDocument::render the SwRenderData is deleted early at the end. When *not* calling ExportSelection this cleanup is not done and the SwRenderData stays until the writer doc is closed. At that time it *will* access data which is long gone (that exists only during PDF export).
That cleanup has to be done in PDFExport::Export after the ExportSelection calls at xRenderable, not in the xRenderable implementation (which is a writer document), but how...?

ALG: The cleanup has to be done; thus calling render in some way is even necessary when nothing is to be rendered. To trigger this, somehow in the render call information has to be given for this special operation. There are various alternatives to do that, checked with giving a special value as nRenderer and reacting on it in the render implementation (SwXTextDocument::render) by doing the needed cleanup. This works (I will add example patch), but is a hack itself. To change the writer implementation to work more clean if getRendererCount is used but render is not is not an alternative, too complex to do.
There is another alternative; try to watch for the ViewShell which is deleted already and causes the crash to be deleted and do the cleanup there. CHecking this...

Created attachment 80791 [details]
ALG: A possible solution, but a hack

ALG: Got a solution to react on ViewShell change. In SwDocShell::SetView it is possible to access the SwXTextDocument. Added a method there (CleanupViewShellDependentIssues) which does the needed cleanup. Tested, works well. This means that cleanup when not calling render is no longer required, but postponed to changes of the model. Due to this I also checked exporting twice (with the error) and mixes of printing and exporting in the same document while it's open, looks good. Adaping a little bit, adding comments...

ALG: Changed function name to 'ReactOnViewShellChange', checked again, works well. Changes now only happen on the writer side what is a much better solution than in filter; changes there would have risked that any other implementation of XRenderable might react differently on the cleanup-render-call. Preparing checkin...

ALG: Okay, comitted, done.

"alg" committed SVN revision 1490593 into trunk:
i121125 Secured release of remembered data (ViewShell) in PDFExport when noth...

grant showstopper flag to get a clear status, already fixed

It's verified fixed in revision 1499347, no crash is seen.

(In reply to Armin Le Grand from comment #11)
> ALG: The cleanup has to be done; thus calling render in some way is even
> necessary when nothing is to be rendered. To trigger this, somehow in the
> render call information has to be given for this special operation. There
> are various alternatives to do that, checked with giving a special value as
> nRenderer and reacting on it in the render implementation
> (SwXTextDocument::render) by doing the needed cleanup. This works (I will
> add example patch), but is a hack itself. To change the writer
> implementation to work more clean if getRendererCount is used but render is
> not is not an alternative, too complex to do.
> There is another alternative; try to watch for the ViewShell which is
> deleted already and causes the crash to be deleted and do the cleanup there.
> CHecking this...

XRenderable is also used for printing and the printing already passed a certain option - namely <bLastPage> - the last <render(..)> call to trigger the clean up. Such a <render(..)> call is also made in the printing routines when no regular <render(..)> is made.

(In reply to SVN Robot from comment #16)
> "alg" committed SVN revision 1490593 into trunk:
> i121125 Secured release of remembered data (ViewShell) in PDFExport when
> noth...

These changes solve the crash, but the clean up of the rendering data has also an important purpose by using the holding a reference to a <ViewShell> instance. This purpose is the restore the original view options which were changed for the PDF export resp. the printing.
Thus, the current clean up comes too late.
Example:
- new text document
- insert page number field
- switch view option to view field names (Menu - View - Field Names)
- export to PDF - Pages = "bad input"
--> no crash after closing the text document
--> view option to view field names is not restored.

(a) Is ok 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 and :
I see the error message, but OOo does no longer crash when I close Writer after test.

(b) same good result with  "AOO 4.0.0 Final – German UI / German locale  [AOO400m3(Build:9702)  -  Rev. 1503704 2013-07-16 14:54:56 (Di, 16 Jul 2013)]" on German German WIN7 Home Premium (64bit)", Common 4.0-dev User Profile

(b) Is reproducible with AOo 3.4.1 and with Server installation of  "AOO 4.0.0-Dev – English UI / German locale [AOO400m1(Build:9700) – Rev.1476029  ((2013-04-26))]" on German WIN7 Home Premium (64bit)", own separate user profile

(d) So I would like to select correct target 4.0.0, but because of crippled Target Milestone selector (Bug Bug 123063) no useful info can be left. Latest confirmation for AOO  4.0.0-dev, but because of incomplete LCo selector (Bug 123063) no correct information can be left.

VERIFIED with  "AOO 4.1.0-Dev – English  UI / German locale - [AOO410m1(Build:9750)  -  Rev. 1530680 - 2013-10-11]" on German WIN7 Home
Premium (64bit)", own separate user profile (please see "Bug 123444 - CRASH when choosing "Selection" radio button on "Print" dialog" #c8