WITH clause causes Sybase IQ 16 to crash

[Former Member]

I have a large query with 2 "WITH" clauses (the second "WITH" clause extracts data from the first one). When I run the query it crashes the IQ server (stack trace provided below).

If I understood correctly from this post:

Sybase IQ 16 doesn't support WITH clauses, but why would it then crash the server instead of returning an error?

I tried to solve my problem by increasing the main and temporary buffers (-iqmc -iqtc), but it didn't work.

Any help or tips will be much appreciated

Sybase IQ 16 SP08 PL30

Environment: Windows Server 2008 R2 SP1 x64

Stack Trace:

**  Error from IQ connection:  SA connHandle: 1  SA connID: 17  IQ connID: 0000000013  User: DBA
**  Time of error:  2015-05-07 02:22:11
**  IQ Version:  SAP IQ/16.0.0/150327/P/sp08.30
**  OS info:  IQ built on: MS/Windows 2003,  Executed on: Windows/SAPDI/WinNT/6.1/Build 7601/Service Pack 1/x86 Family/level 6/Model 46/Stepping 6/8 CPU(s)
**  Command status when error occured:  NO COMMAND OR CURSOR ACTIVE
**  Parser command text:  




Dump all thread stacks at stcxtlib\st_server.cxx:846 for PID: 8220





***************** This is the STACKTRACE ***************






 ********************************
 * Generating all thread stacks *
 ********************************



===== Thread Number  9872  (IQ connID: 0000000013) =====
pc: 0x00000000E1746C87:  void __cdecl pcpstack(unsigned long,unsigned long,class db_log * __ptr64,class hos_fd * __ptr64,int) 00000001805e6b70 f hos_stacktrace.obj +0x117
pc: 0x00000000E1748967:  void __cdecl DumpAllThreads(char const * __ptr64,unsigned int,int,unsigned long,unsigned long) 00000001805e8750 f hos_stacktrace.obj +0x217
pc: 0x00000000E15134F1:  void __cdecl hos_ABORT(char const * __ptr64,unsigned int,char const * __ptr64,char * __ptr64,char * __ptr64) 00000001803b3330 f hos_abrt.obj +0x1c1
pc: 0x00000000E1D90C1A:  long __cdecl ExcpFilter(struct _EXCEPTION_POINTERS * __ptr64) 0000000180c30be0 f st_server.obj +0x3a
pc: 0x0000000077189490:  UnhandledExceptionFilter + 352
pc: 0x00000000773A43B8:  MD5Final + 7656
pc: 0x00000000773285A8:  _C_specific_handler + 156
pc: 0x0000000077339D0D:  RtlDecodePointer + 189
pc: 0x00000000773291AF:  RtlUnwindEx + 3007
pc: 0x0000000077361278:  KiUserExceptionDispatcher + 46
pc: 0x00000000E658DE70:  void __cdecl `dynamic atexit destructor for 'vtMissing''(void) 00000001815ae9b0 f comsuppw:comutil.obj +0x3e7f4c0
pc: 0x00000000E658E00D:  void __cdecl `dynamic atexit destructor for 'vtMissing''(void) 00000001815ae9b0 f comsuppw:comutil.obj +0x3e7f65d
pc: 0x00000000E658E020:  void __cdecl `dynamic atexit destructor for 'vtMissing''(void) 00000001815ae9b0 f comsuppw:comutil.obj +0x3e7f670
pc: 0x00000000E658E758:  void __cdecl `dynamic atexit destructor for 'vtMissing''(void) 00000001815ae9b0 f comsuppw:comutil.obj +0x3e7fda8
pc: 0x000000006C2C29CE:  public: virtual enum dfo::Status __cdecl df_OmniRowScan::Restart(enum a_cursor_orientation) __ptr64 0000000020322830 f df_omnirowscan.obj +0x19e
pc: 0x000000006C2A9869:  protected: virtual enum dfo::Status __cdecl dfo_Scan::DoFetch(enum a_cursor_orientation) __ptr64 0000000020309820 f dfo_scan.obj +0x49
pc: 0x000000006C2A7793:  protected: virtual enum dfo::Status __cdecl dfo_Scan::DoFirstFetch(enum a_cursor_orientation) __ptr64 0000000020307640 f dfo_scan.obj +0x153
pc: 0x000000006C296FA7:  public: enum dfo::Status __cdecl dfo_Base::Fetch(enum a_cursor_orientation) __ptr64 00000000202f6f30 f dfo_base.obj +0x77
pc: 0x000000006C29E0C0:  protected: virtual enum dfo::Status __cdecl dfo_Root::DoFetch(enum a_cursor_orientation) __ptr64 00000000202fe020 f dfo_root.obj +0xa0
pc: 0x000000006C297AAD:  protected: virtual enum dfo::Status __cdecl dfo_Root::DoFirstFetch(enum a_cursor_orientation) __ptr64 00000000202f7a20 f dfo_root.obj +0x8d
pc: 0x000000006C296FA7:  public: enum dfo::Status __cdecl dfo_Base::Fetch(enum a_cursor_orientation) __ptr64 00000000202f6f30 f dfo_base.obj +0x77
pc: 0x000000006C29B5D9:  protected: virtual enum a_search_status __cdecl dfo_Root::DoFetchRelative(long,long * __ptr64) __ptr64 00000000202fb520 f dfo_root.obj +0xb9
pc: 0x000000006C298CB2:  public: virtual enum a_search_status __cdecl dfo_Root::FetchRelative(long,long * __ptr64) __ptr64 00000000202f8c30 f dfo_root.obj +0x82
pc: 0x000000006C0DA6A8:  enum a_search_status __cdecl move_cursor(struct a_db_cursor * __ptr64,long,unsigned int,unsigned int,unsigned int,unsigned int) 000000002013a620 f ricursor.obj +0x88
pc: 0x000000006C0DB356:  unsigned int __cdecl dbi_fetch(struct a_db_cursor * __ptr64,long,unsigned short,unsigned int,unsigned int,unsigned int,unsigned int,unsigned int) 000000002013b2a0 f ricursor.obj +0xb6
pc: 0x000000006C1C9965:  void __cdecl db__fetch(class Connection * __ptr64,struct an_sqlpres_receive * __ptr64) 0000000020229680 f rnsql.obj +0x2e5
pc: 0x000000006C1DFA22:  public: virtual void __cdecl RequestProcedure::call(void) __ptr64 000000002023f380 f rnstream.obj +0x6a2
pc: 0x000000006C06E2B9:  public: void __cdecl Context::call(class Procedure * __ptr64,class Context * __ptr64 * __ptr64) __ptr64 00000000200ce250 f worker.obj +0x69
pc: 0x000000006C06E580:  public: void __cdecl Worker::call_on_stack(class Procedure * __ptr64) __ptr64 00000000200ce520 f worker.obj +0x60
pc: 0x000000006C1DA317:  public: virtual void __cdecl TopProcedure::call(void) __ptr64 000000002023a2e0 f rnstream.obj +0x37
pc: 0x000000006C070562:  public: int __cdecl Worker::spawn(class Procedure * __ptr64) __ptr64 00000000200d0470 f worker.obj +0xf2
pc: 0x000000006C1DC21E:  public: void __cdecl EngStream::handle_ind(unsigned char,unsigned int) __ptr64 000000002023c130 f rnstream.obj +0xee
pc: 0x000000006C1DD2CB:  public: void __cdecl EngStream::execute(void) __ptr64 000000002023cf90 f rnstream.obj +0x33b
pc: 0x000000006C1DA680:  public: virtual unsigned int __cdecl RQBaseItem::do_work(class Worker * __ptr64) __ptr64 000000002023a650 f rnstream.obj +0x30
pc: 0x000000006C209FDD:  public: static void __cdecl RequestQueue::worker_body(void) 0000000020269f70 f kernel.obj +0x6d
pc: 0x000000006C1DA63B:  void __cdecl request_task(void * __ptr64) 000000002023a5c0 f rnstream.obj +0x7b
pc: 0x000000006C5656FC:  private: static void __cdecl W32Task::pre_body(void * __ptr64) 00000000205c5660 f ntkernel.obj +0x9c
pc: 0x000000007710652D:  BaseThreadInitThunk + 13
pc: 0x000000007733C521:  RtlUserThreadStart + 33
pid = 8220 tEntry.th32OwnerProcessID 8220 tEntry.th32ThreadID 6680 ctid 9872

[Former Member]

Open a case with SAP and refer to CR 781603 as a possible related issue.

[Gisung]

Hi Im Yong So,

I think it might be an exception handling problem.

If you want to know the root cause and workaournd,

you need to open and escalate the incident for further analysis.

==

Gi-Sung Jang